Текст книги "Франчайзи на грани нервного срыва. Как небольшой фирме-партнеру 1С перестать выживать и начать зарабатывать"

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

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

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

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

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

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

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

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

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

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

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

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

Показывать старые черновики мне не хотелось. Вряд ли бы схемы, нарисованные от руки, без соблюдения каких-либо правил, впечатлили Владимира Юрьевича. Но, к счастью, благодаря подключению к Интернет, я прочитал про одну интересную технологию рисования диаграмм. Нотация DFD, возникшая из диаграммы деятельности, использованной в методологии SADT[13]13
  Методология SADT, разработанная Дугласом Россом, представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.


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

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

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

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

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

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

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

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

– А что такое?

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

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

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

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

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

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

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

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

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

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

– Как именно?

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

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

Работа пошла веселее, но все же оказалась в три раза более трудоемкой, чем мы рассчитывали. Вместо двух месяцев мы занимались созданием модели бизнес-процессов «как-есть»[14]14
  Модель бизнес-процессов «как есть» («as-is») – модель существующего состояния организации, которая позволяет систематизировать протекающие в данный момент процессы, а также используемые информационные объекты.


[Закрыть] полгода.

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

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

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

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

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

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


[Закрыть]. Такое отношение к страданиям сохраняет нам хорошее расположение духа. А для успеха бизнеса счастливое состояние руководителя очень важно.

Глава 11. Как не надо оптимизировать снабжение

Я перенес в гараж последний компьютер из багажника своей шестерки и с грустью посмотрел на кучу мониторов и системников. Долго они тут не пролежат, максимум – до осени. Вряд ли они переживут зиму в неотапливаемом помещении. Заржавеют к чертям, а техника – дорогая. Значит, нужно быстро найти новый офис. А как же все хорошо начиналось! Прекрасный заказчик, десяток консалтинговых договоров, семеро сотрудников. Почему же все пошло не так?

Мы встретились с ним в кафе год назад, в самом конце 90-х. Мой старый друг, топ-менеджер Большого предприятия. Пили кофе, и я рассказывал ему о моделях «как есть», «как будет» и о реорганизации бизнес-процессов. Было видно, что он очень заинтересован. Большое предприятие к тому времени сильно выросло, в нем было уже более 3 000 сотрудников, и даже описание существующего документооборота было нетривиальной задачей. А какие возможности открывались для оптимизации!

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

Было очевидно, что один я не справлюсь с проектом. Чтобы выполнить договор в срок, я нанял двух первых сотрудников. Для построения схем процессов мы использовали программный продукт BpWin, обкатанный на электроламповом заводе. На главной диаграмме был изображен перечень отделов, входивших в структуру ФЭС. На диаграмме отдела – перечень функций, которые выполнял отдел. А вот диаграммы функций были поинтереснее. На каждой такой диаграмме изображались наборы данных (документы, отчеты и базы данных), операции по их обработке и исполнители. Информационные потоки моделировались стрелочками. По картинке можно было легко понять, кто и в какой последовательности производит операции по регистрации документов, вводу данных в программы и получению отчетов. Благодаря тому, что BpWin позволял описать связи между диаграммами, можно было отследить весь путь документов между отделами. И посмотреть пример каждого документа – для этого мы сделали около тысячи сканов образцов.

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

– Вот отчет по начислениям в разрезе отраслей, который для вас делает отдел сбыта. Расскажите, что вы с ним делаете?

– С этим отчетом? Ничего не делаем, мы его не используем в работе.

Я переключился на начальника отдел сбыта:

– Скажите, зачем вы делаете отчет, который не нужен плановому отделу?

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

– Но ведь они у вас его даже не просят?

– У меня никто ничего не просит. Я сама все делаю. А разносит все по отделам и складывает в лотки техник.

– Плановый отдел, что же вы делаете с отчетами отдела сбыта из лотка?

– Ну это же не единственный их отчет. Некоторые отчеты мы используем. А этот просто выбрасываем в корзину.

– Отдел сбыта, ну вы можете теперь не делать этот отчет.

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

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

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

Отдел материально-технического снабжения находился в структуре главного технолога. Как я уже писал, Главный технолог был мощной личностью, влияние которого на предприятии было огромно. Под его началом Большое предприятие сильно выросло технически, и он отвечал за надежную работу современного оборудования. Когда мы начали обследование, он вызвал меня к себе. Попросил рассказать о той «шпионской» деятельности, что я веду. И предупредил, что результаты должны быть согласованы с ним до того, как будут представлены директору и начальнику ФЭС. Тогда я понял, что новый директор и главный технолог «не подружились», и наш консалтинговый проект – оружие в борьбе двух топ-менеджеров между собой. «Простите, – сказал я. – Меня сюда привел начальник ФЭС. С ним я все и согласую». Главный технолог промолчал, но дальнейшие события показали, что он мой поступок запомнил и сделал для себя определенные выводы.

В процессе обследования службы снабжения стало понятно, что ее, прежде всего, нужно автоматизировать. Но это не все. Одно из наших предложений состояло в том, чтобы внедрить в ОМТС[16]16
  ОМТС – отдел материально-технического снабжения.


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

– Понимаешь, никакая машина не сможет решить, надежный поставщик или нет. Глупость это. Ты хочешь, чтобы предприятие положилось на программу? А вдруг она не все учтет? Или в ней окажется ошибка? И поставленное оборудование даст сбой и остановит работу предприятия?

– Я думаю, что и люди могут ошибаться.

– Вот, вот. Очевидно, что ты сейчас ошибаешься.

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

И тут случилось неожиданное. Приплыл «черный лебедь», как сказали бы последователи учения Нассима Талеба. На Большом предприятии сменился директор. Новый директор оказался человеком главного технолога. Не прошло и недели, как был уволен мой друг – начальник ФЭС. Я понял, что скоро придут и по нашу душу. Поэтому я не стал дожидаться выселения и в один из вечеров тихонько съехал сам. Перевез временно всю технику в гараж, хорошо, что было лето. Уже на следующий день меня вызвали на совещание.

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

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

Тогда я понял несколько важных вещей.

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

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

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