Развитие предприятия

Гончарук В.А

Начало в выпусках: #149, #150, #151, #152, #153, #154, #155, #156, #157, #158, #159, #160, #161, #162, #163, #164, #166, #167, #168, #169, #170, #171, #172, #173, #174, #175, #176, #177, #178, #179, #180, #181, #182, #183, #184, #185, #186, #187, #188, #189, #190, #191, #192, #193

Цели и концепция

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

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

На нулевом этапе разработки определяются ее цели и концепция. Здесь приходится решать главный вопрос внедрения изменений: что приоритетно тактика или стратегия? В любом деле достаточно легко предъявить яркие быстрые результаты, снимающие сиюминутные проблемы (например, красивый график приходов на дисплее руководителя), но кардинальные стратегические преимущества достигаются долгим кропотливым трудом.

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

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

Пропишем процедуры

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

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

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

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

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

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

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

Проверка, обучение

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

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

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

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

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

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

Как уже отмечалось, процесс разработки охватывает длительный период, на протяжении которого меняются рыночная ситуация, стратегии организации, а значит, и задачи АСУ. Сама программа вводится в эксплуатацию функциональными блоками. Этапность построения при этом должна быть сохранена: цели и концепция программы > формализация бизнес-процессов > экспериментальная отработка > обучение.

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

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

Продолжение в выпусках: #195, #196, #197, #198, #199, #200, #202, #204, #205, #206, #207, #208, #209, #210, #211, #213, #214