Записки автоматизатора. Профессиональная исповедь - Орлов Андрей Александрович 4 стр.

1.4. Задачи автоматизации

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

1.4.2. Ограничения по срокам фактически отсутствуют (поскольку все должно было работать вчера), ограничения по средствам также не определяются, хотя, по всей видимости, существуют.

1.4.3. Оценки эффективности той или иной информации для корпорации (убытки из-за отсутствия информации, прибыли от ее наличия) не проводились или недоступны.

<…>

1.6. Проблемы автоматизации

1.6.1. Рабочие места. Отсутствие рабочих мест суммарной стоимостью не более $2000 на человека для специально нанятых высокооплачиваемых сотрудников удивляет. Очевидно, что производительность труда человека, не имеющего даже собственного стула, не может быть высокой при всем его желании работать, которое тоже быстро исчезает.

1.6.2. Интерфейсы. Получение информации и общение с руководством происходит через «игольное ушко» – постоянно загруженного финансового директора. По всей видимости, этот документ тоже осядет в его портфеле. Доступ к сотрудникам корпорации для получения информации напрямую затруднен в связи с загруженностью последних и, может быть, из соображений секретности.

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

На другом после обследования консультантов просили вернуть все копии документов (отдельно оговорив«„включая электронные копии“«).

Секретность – вообще область интересная. Мне рассказывали, что одну девушку просили после перемены фамилии заново пройти инструктаж по безопасности. – Д. К.

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

1.6.4. Финансовые ресурсы. Никому не приходит в голову выбирать себе автомашину «вообще» – каждый привязывает этот процесс к своему кошельку. Некоторые останавливаются на городском транспорте. У меня есть подозрение, что я оптимизирую выбор между «Роллс-Ройсом» и шестисотым «Мерседесом», когда денег хватит в лучшем случае на «девятку».

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

<…>

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

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

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

«Зачастую исполнительный директор страшно горд тем, что придумал велосипед с шестиугольными колесами вместо использовавшегося им ранее велосипеда с квадратными колесами. Он и не подозревает, что у нормальных людей колеса давно круглые». Эту фразу я услышал в 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 %», или попытки сравнивать программы на основании получаемого разработчиком дохода от продаж. – Д. К.