Записки автоматизатора. Профессиональная исповедь

Теперь вы поняли, что если вы работаете в таких условиях, то здесь я вам не помощник. Дерзайте сами. Ведь именно вы – «высококлассный профессионал-постановщик».

Но предположим, что вы все-таки догадались, что вам нужно сделать.

Очень много сил уйдет у вас на попытки объяснить руководству, что в учете не надо изобретать велосипед.

«Зачастую исполнительный директор страшно горд тем, что придумал велосипед с шестиугольными колесами вместо использовавшегося им ранее велосипеда с квадратными колесами. Он и не подозревает, что у нормальных людей колеса давно круглые». Эту фразу я услышал в 1996 году от А. В. Ширченко. К сожалению, я попытался записать ее по памяти только лет через пять, и поэтому цитата может быть неточной.

Почему-то особенно тяжело доходит, что бухгалтерский учет итальянцы изобрели еще в XV веке для того, чтобы считать свои деньги, а вовсе не для того, чтобы морочить голову государству. Поэтому и ныне его можно эффективно использовать для той же цели.

Еще интереснее, если ругательства используются, но вот смысл в них вкладывается совсем другой. Например, мало кому можно объяснить, что «центр затрат» – это совсем не синоним выражения «подразделение, не приносящее дохода». – Д. К.

Страшно начальникам, не отличающим двойную запись от двойной бухгалтерии. Про водку они обычно знают все, а на бухгалтерскую проводку они и взглянуть боятся. Может быть, у вас что-нибудь получится, если вы клятвенно заверите руководство, что, несмотря на использование стандартных бухгалтерских методик и систем в отчетах, с которыми будут работать они, не будут встречаться бухгалтерские «ругательства» (типа баланс, актив, пассив, дебетовое сальдо и кредитовый оборот по субсчету)

Научитесь

Если, прочитав предыдущую часть записок, вы надулись от гордости за себя и свою профессию, то теперь самое время сдуться обратно. Потому что настало время учиться.

Все фирмы функционируют приблизительно одинаково? Вы все и так хорошо знаете? Тогда скажите, какая разница существует между терминами «заказчик» и «клиент»?

Если не знаете, то вам, наверно, рано писать задание для автоматизации учета в морге или крематории.

Простенький вопрос: может ли уменьшение розничной цены привести к уменьшению объема продаж в штуках? Нет? Вы уверены?

Ответ. При внедрении информационной системы в компании, владевшей газетными киосками в метро, киоскеры стали жаловаться на снижение продаж из-за того, что цены на газеты были заданы с точностью до копеек: возня со сдачей приводила к формированию очереди, и покупатели уходили в соседний киоск, где те же газеты стоили дороже, но не было очереди. Цены округлили до полтинника в большую сторону, и количество продаж увеличилось.

К сожалению (или к счастью – как для кого), чтобы разработать хорошую систему, вам следует быть не только прекрасным знатоком всех областей ИТ – вы еще должны разбираться в работе каждого подразделения своей фирмы не хуже, а лучше руководителя этого подразделения. Только тогда предлагаемые вами решения будут если не оптимальными, то хотя бы работоспособными.

Еще один пример. У фирмы, на которую вы работаете, есть два магазина: в центре Москвы и у кольцевой дороги вокруг Урюпинска. Соответствующий менеджер убеждает вас, что цены в этих магазинах одинаковы, всегда были одинаковы и будут одинаковы вечно.

Вы должны понимать, что в этом случае вечность может закончиться через неделю, и если:

– цены в магазинах не будут выравниваться системой автоматически до окончания вечности;

– цены в магазинах не смогут стать разными сразу после ее окончания, то вы спроектировали систему плохо.

Одновременно с изучением надо тем или иным способом описать существующую технологию работы фирмы. Это очень нудно, но необходимо. Тому, что это делать необходимо, меня учили в институте еще при советской власти, тридцать лет назад. Технологию редко кто описывал по-человечески раньше, ее редко описывают нормально и сейчас. Причиной тому служит кажущаяся бессмысленность этой работы: старая технология после описания сразу же изменяется, а новая всегда тоже отличается от описанного в проекте варианта. Да и средств отразить все нюансы технологии не существует.

Тем не менее я продолжаю считать не только полезным, но и необходимым скрупулезное описание технологии функционирования организации как на этапе обследования, так и на этапе проектирования.

Утешением вам может служить то, что на этом этапе вы в первый раз можете принести существенную пользу своей фирме (правда, я не уверен, что это оценят. Не исключено, что, напротив, скажут: «Сует нос куда не надо»). Следующий раз будет только после внедрения, а будет ли еще внедрение…

В качестве средства описания мне до сих пор нравятся старые добрые структурно-информационные временные схемы (СИВС), так как на них даже руководству видно, через какое место организован документооборот, но используемые средства определяют скорее эстетику документации. А вот если вы не можете описать технологию никак, это, очевидно, характеризует или вас, или фирму.

В отзывах на первую интернет-публикацию записок достаточно часто спрашивали, где можно почитать про СИВСы. Все поисковые сервера Интернета при попытке что-нибудь о них узнать, дружно отправляют меня к моим же запискам. Похоже, что вся информация так и осталась в 1970-х…

Это не так. Сейчас это именуется dataflow diagram (или audit diagram, или еще как угодно в зависимости от рассказчика) и используется при описаниях процессов. Один из примеров СИВС-подобной нотации – ARIS EEPC, используемая в одноименном продукте (к сожалению, сильно недешевом). – Д. К.

СИВСом называлась диаграмма, по оси абсцисс которой откладывалось время, а по оси ординат – организации, структурные подразделения или сотрудники. Когда меня учили, на СИВСе отображали документы и действия с ними. Я размещаю на СИВСе все объекты, которые существенны в бизнес-процессе, включая пачки денег и товары, если это необходимо. Получается очень наглядно и понятно даже неспециалисту. Не слишком хорошо удается отобразить только циклы. Для их отображения я просто выделяю участок диаграммы, под которым пишу текстом «Повторяется 10 раз» или «Повторяется, пока все не согласятся с текстом»

В последние годы для рисования СИВСов я использую Microsoft Visio. Пример приведен ниже.

Да, вполне достаточно любой рисовалки, хоть текстового редактора (даже лучше не увлекаться дорогими продуктами, так как смысл работы может утонуть в процессе увлекательного освоения ультрамодной технологии). – Д. К.

Рис. 5. Пример фрагмента СИВС

Следует отметить, что СИВС в моей интерпретации не предполагает автоматической генерации программ и баз данных. Эта штука принципиально недоформализована, что позволяет ее делать настолько наглядной, насколько это нужно. Если же вы хотите автоматизировать всю разработку от описания бизнес-процессов до кодов, то нужно использовать те средства поддержки case-технологии, которые сейчас есть на рынке.

Окопайтесь

Помимо осознания информационных потребностей компании вам еще очень неплохо сформулировать основные задачи ИТ-подразделений. Не надейтесь, что ваше мнение на этот счет совпадает с мнением руководства. На самом деле подразделения ИТ не только могут работать, но и на самом деле работают, руководствуясь разными целями, и единодушие среди топ-менеджмента хотя бы в этих вопросах будет для вас совсем не лишним. Разберем пример документа.

Концепция управления подразделениями ИТ

1. Направление ИТ состоит из подразделений, занятых в основном обслуживанием других подразделений компании, обеспечивающих поступление прибыли. Сами подразделения ИТ планово затратны и не ориентированы на получение прибыли с помощью продажи оборудования, программ или услуг.

Это означает, что при проектировании программного обеспечения и проработке технологических решений подразделения не закладываются средства на возможность дальнейшей продажи решений, поскольку последнее требует существенно больших ресурсов в процессе разработки. С другой стороны, топ-менеджмент компании не рассчитывает на продажу этих решений и не соблазняет такими мыслями сотрудников ИТ-подразделений. Следует помнить, что предпродажная подготовка программного продукта может составлять более девяноста процентов его стоимости.

2. Сотрудники ИТ-подразделений могут иметь и высказывать свое мнение по вопросам организации торговли, развития фирмы и другим вопросам, находящимся вне зоны их основной специализации, но всегда выполняют решения профильных менеджеров компании, какими бы странными они им ни казались.

Как мне кажется, для этого пункта альтернативы не существует. То есть она есть, но ровно одна: айтишник становится исполнительным директором или кем-то похожим. Но в этом случае он перестает быть айтишником…

Как следствие, инициативы создания и развития программных продуктов пресекаются, если они не одобрены топ-менеджментом компании.

3. Существуют приоритеты в очередности использования ресурсов для решения задач подразделениями ИТ (представлены в порядке убывания значимости для компании, в которой вы работаете):

– Обеспечение возможности принятия стратегических решений топ-менеджментом компании (организация учета и отчетности, позволяющей принимать решения);

– Увеличение количества продаж (изменения в ПО для проведения торговых акций) и скорости продаж в магазинах (изменения ПО для облегчения и ускорения работы в кассовых программах);

– Обеспечение роста производительности и удобства работы других пользователей.

Полезно также помнить, что автоматизация учета должна предшествовать автоматизации планирования. Почему-то иногда пытаются сделать наоборот. – Д. К.

Тоже вроде все ясно. Но хочется, чтобы все желания исполнялись сразу. Я в таких случаях цитирую концовку сказки Сергея Михалкова «Жадный Вартан»: «Больших семь шапок из овцы / Не выкроишь никак!»

Есть три сказки, с помощью которых удобно иллюстрировать процесс постановки задачи и последующего внедрения.

1. «Жадный Вартан» (когда урезанный бюджет приводит к сильному сужению рамок проекта, что иногда выливается во внедрение журнала хозопераций вместо полноценной системы).

2. «Каша из топора» (когда заключается договор с узкими рамками, которые впоследствии вместе с бюджетом плавно расширяются внедренцем).

3. «Сытный бублик» (когда результат достигается только после многочисленных недовнедрений, в процессе которых набирается опыт и появляется понимание того, какой все-таки был необходим результат). Последняя попытка в таком случае оказывается удачной, и руководитель восклицает, подобно деду из сказки: «Что же ты мне сразу этот сытный бублик не дала?!» – Д. К.

4. Предложения по доработкам и развитию ПО и оборудования могут выдвигать и обсуждать все сотрудники компании, однако выполнению подлежат только заявки, утвержденные руководителями направлений уровня заместителя директора.

Вас удивляет, что это надо писать? Вот поверьте, надо.

И принимайтесь за работу

Теперь вам придется определиться, воспользоваться покупной системой или программировать самим. И то и другое имеет свои очевидные минусы: покупные системы никогда не заточены под ваши задачи, а на собственную требуется такое количество ресурсов (и денег, и людей, нанимаемых не на постоянную работу, а «под задачу» – что, бесспорно, ускоряет решение этой задачи, – и, что самое важное, времени), какое в большинстве случаев просто недоступно.

Что касается собственной разработки, то можно почти с уверенностью сказать, что седло у велосипеда, который изобретете вы, будет удобно для зада вашего хозяина. Не вполне ясно только, будет ли этот велосипед ездить. И чем крупнее и многопрофильнее компания, тем меньше шансов, что такая работа когда-нибудь завершится. Впрочем, и в последние годы я видел завершенные проекты. Но мало.

Если вы остановились на покупной системе, то ее, к сожалению, нужно выбрать. Выбор богатый, и все варианты вам, конечно, не нравятся. Но кажется, тут я вам могу немного помочь.

Выбор системы

Вот уж в чем сейчас недостатка нет, так это в статьях по выбору тиражируемой информационной системы и компании-внедренца. Появились даже фирмы, специализирующиеся на консультационных услугах по выбору тиражируемых

Такие уже есть. – Д. К.

информационных систем. Подозреваю, что скоро появятся фирмы, специализирующиеся на выборе таких консультантов. Кстати, среди статей встречаются вполне разумные. К сожалению, во многих других случаях при чтении статьи необходимо держать в голове, где работает автор и продажу каких систем проталкивает.

Ангажированность авторов, изучающих и обозревающих эти вопросы, зачастую видна уже на уровне определений и классификации. Очень много сил отдано проработке определения КИС – корпоративной информационной системы, ИУС – информационно-управляющей системы, ИСУП – интегрированной системы управления предприятием, системы класса ERP – Enterprise Resource Planning, ERPII, стандарта MRPII – Manufacturing Resource Planning. После того как определение тем или иным способом сформулировано, обычно делается вывод, что информационная система, продвигаемая авторами публикации, определению соответствует, в отличие от систем-конкурентов.

Да, это все равно что говорить, что продукт соответствует стандарту ISO 9000 (видел я и такое). – Д. К.

При этом ERP-стандарта попросту не существует, а MRPII американской ассоциации управления производственными ресурсами APICS – это концепция управления производством и запасами, то есть методология менеджмента, а не стандарт информационной системы.

Когда вы подбираете систему, вам не очень интересно знать, является ли она настоящей полнофункциональной кисой в понимании эксперта NN. Почему какая-то функциональность называется полной? Полной для какого предприятия? Как должна влиять на мой выбор информация о том, что система удовлетворяет информационные потребности девяти из десяти организаций, если я работаю как раз для десятой? И почему я в этом случае должен платить за систему дороже? Так что вам в любом случае придется сравнивать перечень нужных вам функций с перечнем функций рассматриваемой системы. Причем по названиям функций вы ничего не поймете, названия у всех разработчиков поворачиваются по веянию моды, как флюгер, гораздо быстрее, чем в систему вносятся необходимые изменения. В какой системе сейчас нет логистики, бюджетирования, МСФО? И как вы удивитесь, когда поймете, что имел в виду разработчик… Но об этом ниже.

Тем более удивляет огромное количество публикаций консалтинговых компаний, проводящих сравнение программ по их функциям. Читая такие обзоры, часто понимаешь, что сделаны они именно по названиям функций. На такие рейтинги и обзоры часто любят ссылаться продавцы систем («Наша система набрала 99 очков из 100 по шкале компании Ы» или «По оценке экспертов N наша система является лидером в области Э»). Встречаются даже совсем курьезные тексты – например, описания того, что «система N повышает удовлетворенность пользователей на 30 %», или попытки сравнивать программы на основании получаемого разработчиком дохода от продаж. – Д. К.

Тем не менее некоторые характеристики, очевидно, служат для отбора систем до их подробного изучения. К таковым относятся:

– максимальное количество рабочих мест, на которое рассчитана система;

– оценочная стоимость и продолжительность внедрения;

– место разработки системы: зарубежная или отечественная;

– возможность дорабатывать систему под нужды клиента (открытость системы).

Максимальное количество рабочих мест

Этот показатель позволяет сразу отсечь маломощные системы, созданные с использованием устаревших программных средств общего назначения (СУБД и операционных систем) и устаревших технологий. Кажется разумным отсекать те системы, максимальное количество рабочих мест в которых меньше удвоенного, а еще лучше утроенного количества рабочих мест, закладываемых в проект. Понятно, что даже если вы информацию о количестве рабочих мест получаете у разработчика, он должен дать вам адрес и телефон организации, где система на этом количестве рабочих мест функционирует.

Техническими параметрами системы в ходе внедрения управлять гораздо сложнее, чем бизнес-логикой (трудно заставить систему, рассчитанную на работу двадцати пользователей, обслуживать пять тысяч операторов). Поэтому именно на технические параметры стоит обращать больше внимания. А рассматривая технические характеристики, не лишне также заранее подумать, как же будет работать система, если необходимый для ее функционирования ресурс, воспринимаемый разработчиком как навечно данный от Бога, вдруг перестанет быть таковым (например, предположение о том, что каналы связи от Москвы до подразделения в Магадане вдруг могут перестать работать, может привести к выбору системы, поддерживающей работу с распределенной базой данных).

Значение технических характеристик существенно еще и потому, что бизнес-логику одной системы гораздо легче скопировать в другой (в результате чего во многих системах, особенно западных, заложены практически идентичные процессы). Быстродействие и возможность поддержки больших объемов данных из удачной системы скопировать гораздо труднее.

Оценивая производительность системы, нужно также обращать внимание и на то, какая функциональность использовалась пресловутыми тысячами пользователей в компании N. Хотя факт запуска на огромных объемах данных или на большом количестве рабочих мест и свидетельствует о возможностях системы, но совсем не гарантирует, что именно локализация для вашей страны или решение для вашей отрасли будут работать. – Д. К.

Оценочная стоимость и продолжительность внедрения

В большинстве случаев компании, осуществляющие внедрение информационных систем, стараются заранее занизить оба показателя в надежде, что клиент доплатит и подождет, оказавшись с неработающей системы после того, как закончились и выделенные деньги, и выделенное время. С другой стороны, после получения первых порций денег внедренцы всегда в состоянии довести оба показателя до любой величины, если заказчик не разорится раньше.

Реальным критерием является лишь минимальная величина по полномасштабным осуществленным проектам. Сейчас такие оценки достаточно часто встречаются в обзорных статьях.

Только поймите, это не те сумма и время, которые потратите вы. Эта те сумма и время, меньше которых вы не потратите точно.

Настройки и коды

Любую тиражируемую систему нужно настраивать для конкретной организации. Это ни у кого не вызывает возражений. Точно так же не вызывает возражений, что настройка лучше дописывания или изменения программных кодов. Вот только что считать настройкой, а что кодами?

Пока нужно ставить галочки в табличках, выбирать какие-то значения из списка и даже вписывать какие-то числа, это точно настройка.

Пока пишешь формулы для расчета цен и сумм проводок в типовых операциях, это, наверное, тоже настройка.

Если таким формулам предшествуют условия, при которых они применяются, то я готов и это признать настройкой.

Но дальше – больше, потребности растут, и вот разработчик добавляет в систему свой корявый алгоритмический язык и обзывает тексты на нем тоже настройкой.

Осмысленность последнего для меня очень сомнительна. С одной стороны, обычно у разработчика информационной системы нет специалистов для создания хороших интерпретаторов и трансляторов, так что результат получается чрезвычайно убогим, а с другой – основная сложность в программировании на известных алгоритмических языках состоит отнюдь не в том, что используемые ключевые слова написаны по-английски. Человек либо может описать алгоритм, и тогда в течение недели сделает это даже на языке с ключевыми словами на суахили, или не может, но тогда его не спасет то, что вместо «go to» нужно писать «идти на».

Для меня самого разница между настройкой и программированием, к примеру, для модулей бухучета определяется очень просто: если такую работу может сделать квалифицированный бухгалтер, то это настройка. Если для этого нужен программист, то это программирование. Другое дело, что «настроечное» программирование не должно задевать ядра системы, но для этого давным-давно разные способы придуманы.

К настроечной части системы также принадлежат генераторы экранных и печатных форм и генераторы отчетов. Они очень облегчают жизнь, позволяют использовать на сопровождении часть специалистов более низкого уровня квалификации. Только моя практика показывает, что с их помощью удается легко решать только простые задачи, а в сложных случаях все или зависает, или начинает работать очень-очень медленно.

Российский самопал или крутой Запад?

Да, в западные системы денег обычно вбухано гораздо больше, чем в российские (только вот в разработку или в пиар?). Правда, надо учесть, что и программист российский стоил до недавнего времени в пять раз дешевле аналогичного западного.

Одной из мантр поставщиков ERP является утверждение, что на разработку системы потрачены тысячи человеко-лет. И действительно, в компаниях, поставляющих крупнейшие ERP-системы, работает очень и очень много квалифицированных специалистов. Однако следует обратить внимание на следующие моменты:

– большинство этих специалистов работает вовсе не над теми проблемами, которые стоят перед вами;

– численность людей, занятых локализацией продукта, вполне может быть сопоставима с численностью специалистов, занятых поддержкой этого продукта у заказчика;

– огромное количество этих человеко-лет потрачено на функциональность, которая никогда на данном конкретном предприятии использоваться не будет;

– попытка доработать тиражную систему может оказаться гораздо сложнее разработки с нуля, так как поневоле придется поддерживать часть ненужной на конкретном проекте функциональности и бороться с чужим программным кодом (это, кстати, также одна из причин того, почему заказная разработка всегда будет работать на порядок быстрее). —Д.К.

Да, количество внедрений конкретных зарубежных систем на порядки выше, чем российских (если, конечно, не считать 1С), поэтому системы более отлажены. Но это не касается их российской локализации, которая, кстати, делается российскими программистами. Посему не удивляйтесь, если в какой-то момент система в задумчивости начнет разговаривать с пользователями на английском языке или на таком русском, что уж лучше бы она это на английском делала: хоть кто-нибудь бы понял.

То, каким образом система поддерживает российское законодательство и российские обычаи, тоже следует изучать очень подробно и скрупулезно.

Самая крупная для нас неприятность в зарубежных системах состоит в том, что они обычно ориентированы на наличие общего стандартного регламента управления деятельностью предприятий, который пока почти не применяется в России. Посему компания, осуществляющая внедрение, вместо настройки системы под существующие в организации бизнес-процессы в большинстве случаев предлагает выполнить «реинжиниринг» бизнес-процессов, чтобы они соответствовали бизнес-процессам и технологиям, предусмотренным в данной системе, то есть перестроить всю технологию работы организации.

Если уж вы выбираете импортную систему, то вряд ли у вас получится просто создать накладную на отпуск товара, если товар не оприходован на складе. В отечественных системах контроль ухода остатков в минус обычно можно включить или выключить, и везде, где я работал, меня просили этот контроль выключить.

Чтобы понять некоторые неудобства от работы с такой системой, вспомните свой опыт работы с MS Word, который всегда лучше вас знает, как форматировать текст, нумеровать и оформлять списки, учит вас, что в русском языке прилагательные c приставкой «не» всегда пишутся отдельно, и предлагает исправить выражение «номинировать на конкурс» на правильное: «но минировать на конкурс». Если вас это все не бесит, вы, может быть, и с иностранной системой уживетесь.

Изучая ИХ системы с точки зрения бухгалтерского учета, понимаешь, как ИМ ТАМ хорошо живется: в типовых настройках одной экономической транзакции соответствует одна бухгалтерская проводка. И еще одна на НДС.

– А больше можно? Ведь нам даже в официальном учете их необходимо сделать пять.

– Можно, если скриптик написать.

Я уж не говорю про желание вести параллельно «управленческий» и «официальный бухгалтерский» учет. Да нет, я даже не про черный и белый. Я про желание вести учет по какому-нибудь международному стандарту, чтобы его зарубежный инвестор понимал, и по российскому, чтобы перед налоговой отчитываться. Не понимают этого ни люди иностранные, ни системы: учет может быть только один.