Глава 10. Как смоделировать систему учета на заводе

Дело происходило в конце 90-х. Я еще работал в Сотовой связи, но уже начал подрабатывать консультациями. Ко мне часто обращались старые знакомые со своими проблемами. И я пытался решать их, используя свои опыт и знания.

В тот день позвонил начальник АСУ Лампового завода. У него возникла проблема. Ему надо было автоматизировать производство на основе той программы, что мы сделали на заводе несколько лет назад.

– Слушай, я набрал себе программистов. Они освоили вашу программу благодаря «дереву»...

– О, «дерево», вам, значит, помогает?

Я вспомнил, как создавал специальную программу для работы с ERP-системой завода. Она позволяла автоматически построить иерархическую структуру вызова всех процедур, начиная с главной программы. Быстро найти нужную функцию в этом каталоге и внести в нее изменения, не вспоминая имя и расположение программы на диске. Там же был и список всех таблиц, с которыми работала программа. Можно было менять их структуру «влёт». Очень удобная система, чем-то похожая на систему проектирования прикладных решений, которую сейчас использует фирма 1С.

– Конечно. А еще у нас классные специалисты в бухгалтерии и на производстве. Они работают на заводе очень давно и хорошо его знают.

– Так в чем же дело?

– Понимаешь, бухгалтеры и программисты говорят на разных языках. Никак не могут друг друга понять. Короче, у меня нет постановщика задач. Сам я почти все время трачу на сопровождение расчета зарплаты, и мне не до того. Как вы справлялись со всем, когда писали программу? Что делали?

Я вспомнил, как мы автоматизировали завод. Рисовали схемы бизнес-процессов «как есть» на коленке. Собирали образцы документов. Интересно, сохранились ли эти черновики? Но даже если и сохранились, вряд ли они могли бы помочь. В производство мы не лезли, не было такой задачи. Однако другу надо было помочь.

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

– Хм, интересно. А можешь показать то, о чем рассказываешь?

Показывать старые черновики мне не хотелось. Вряд ли бы схемы, нарисованные от руки, без соблюдения каких-либо правил, впечатлили Владимира Юрьевича. Но, к счастью, благодаря подключению к Интернет, я прочитал про одну интересную технологию рисования диаграмм. Нотация DFD, возникшая из диаграммы деятельности, использованной в методологии SADT в конце 1970-х годов. На диаграмме DFD изображалась информационная система. Она принимала потоки данных из внешних сущностей. Внутри системы данные изменялись в действиях по преобразованию информации. Новые данные из выхода одних действий могли поступать на вход к другим. А также помещаться (и извлекаться) в накопители данных. Наконец, система передавала преобразованные данные к внешним сущностям. Кроме того, модель DFD была иерархической. Любое действие можно было декомпозировать, то есть разбить на части и изобразить на отдельной диаграмме.

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

Я сел за компьютер и по памяти нарисовал одну диаграмму для внедренной системы. План продаж (поток данных) поступал от директора по сбыту (внешняя сущность) на исполнение в отдел продаж. Информация об отгрузках (поток данных) накапливалась в накопителе (база данных программы «Свет»). Планы и отгрузки поступали на вход действия «подготовить отчет о выполнении плана продаж». Готовый отчет попадал во внешнюю сущность (генеральному директору). Кликнув на стрелку «План продаж», я сделал ссылку на файл Excel, в котором, опять же, по памяти, нарисовал пример плана. Номенклатура, цена, план продаж в штуках. Такую диаграмму не стыдно было показать Владимиру Юрьевичу.

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

Сам я не мог выполнять эту работу, я все еще работал в Сотовой связи. Но у меня был замечательный соратник, с которым мы прошли вместе огонь и воду. Моя жена Татьяна. Она подумывала, не выйти ли ей из декретного отпуска пораньше. А тут я со своим договором. «Танюша, тут работы на месяц. Максимум – на два. Но мы получим замечательный опыт описания бизнес-процессов в модной нотации. Да и ребятам с завода поможем. Помнишь, как мы его автоматизировали? Здорово было, правда?» Танюша рассмеялась, вспоминая, как я приходил домой в три ночи, но согласилась. Ей было интересно попробовать консалтинговый проект.

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

Через две недели такой работы у нас с Татьяной состоялся серьезный разговор.

– Слушай, ты и вправду думаешь, что мы справимся за месяц или два?

– А что такое?

– А то, что у меня собралась кое-какая статистика. Те процессы, что я уже описала. И те, что осталось описать.

– Любопытно. И что у тебя получается?

– 10 месяцев. Может быть, год.

– Что?! Да не может быть! Я думаю, все ускорится по мере того, как ты работаешь. Мы же только начали. Набираем темп.

– Ускорится, конечно. Да, все будет быстрее. Не 10 месяцев. И, конечно, не год. Думаю, управимся за 9 месяцев.

– Не прикалывайся. У нас бюджет на два месяца максимум.

– И что будем делать?

– Поговорим с Владимиром Юрьевичем.

Мы пообщались с директором по ИТ. Он сказал, что не сомневается в наших расчетах. Все понимает. И готов увеличить сроки. Но с суммой ничего сделать не может. Бюджет был выбит с трудом. Директор завода не понимал, зачем кому-то платить, если есть свое АСУ.

– Ладно, – сказал я. ? Если уж мы договорились, работу сделаем. Не в моих привычках что-то бросать на полпути. Но ты должен нам помочь.

– Как именно?

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

– Ладно, с этим поможем.

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

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

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

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

Подведем итоги. Для того чтобы программисты могли программировать, а пользователи – формулировать четкие требования, нужны посредники. Они называются бизнес-аналитиками. Такую роль на заводе сыграли мы с Татьяной. Бизнес-аналитики понимают пользователей. Разбираются в предметной области. Понимают, как устроены системы. Умеют отделять систему от ее окружения, формировать границы для решаемой задачи. Могут видеть информационную систему как совокупность процессов, обменивающихся информацией. Легко отделяют входную информацию от выходной. А еще бизнес-аналитики умеют разговаривать на языке, понятном программисту. Умеют формализовать требования в виде общепринятых нотаций и образцов документов. Для того чтобы результаты работы были понятны и пользователям, и программистам, бизнес-аналитики используют специальные инструменты. Не только программу BpWin, умеющую строить диаграммы в нотации DFD, но и другие case-средства, позволяющие создавать функциональные и информационные модели систем управления предприятием «как есть». О том, как правильно формулировать требования к будущим информационным системам и какие инструменты использовать, можно подробнее узнать из литературы, список которой приведен в конце книги.

Хочу также обратить ваше внимание на другую важную проблему, используя мой рассказ, как пример. Перед началом работы мы не всегда можем точно угадать ее трудоемкость. О том, какие инструменты можно использовать для оценки работ, я расскажу в третьей части своей книги. Сейчас же поговорим о том, что мы делаем, если сильно промахнулись с оценкой, и реальная трудоемкость существенно превышает плановую. Прежде всего, мы проводим переговоры с заказчиком. Часто клиенты с пониманием относятся к ситуации с неверной оценкой трудоемкости и готовы идти на изменение стоимости. Однако никто не согласится на рост цены в несколько раз. В этом случае мы обсуждаем, какую не очень ценную для заказчика, но очень трудоемкую работу можно было бы не делать. Если такой работы не находится, остается последнее средство – передача части работ сотрудникам заказчика. Как правило, ИТ-служба заказчика – на нашей стороне. Ей нужен завершенный проект. И она может помочь ресурсами. Тем более, что им в дальнейшем сопровождать создаваемую систему. Участие специалистов заказчика в разработке системы позволяет им глубже изучить программу и лучше справляться с поддержкой.

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

Отправить