|
|
|
|
|
Развитие предприятия 4. Что менять 4.4. Структура и технологии 4.4.6. Построение автоматизированной системы управления (АСУ)Поскольку информация является основой управления, и полностью определяет внешние и внутренние взаимодействия предприятия, вопрос ее системной организации становится ключевым уже на стадии "семейного" бизнеса, и не теряет актуальности в дальнейшем. В недалеком прошлом возможности данной области ограничивались бюрократическими процедурами движения документов и запечатлелись в сознании людей в этом качестве. Появление компьютеров на рабочих местах открыло новые горизонты (у нас - лет на 20 позже, чем на западе), но опыт применения интегрированных систем, очевидно, придется нарабатывать еще долго. Мы рассмотрим некоторые фрагменты данного опыта (преимущественно, торговых организаций), "трудные места" разработки и внедрения АСУ, попытаемся выстроить логику ее создания. В нормальных условиях недавно созданное предприятие начинает автоматизацию с регламентированного законом бухгалтерского учета. Здесь еще не существует серьезных проблем - благо, в недорогом программном обеспечении для малого бизнеса недостатка нет. Рыночная и управленческая информация довольно долго циркулирует в "семейной" структуре бессистемно, первые попытки формализации потоков осуществляются через тетрадки сбытовых менеджеров и введение правил документооборота. Следующим этапом часто становится использование стандартных относительно маломощных приложений Windows и покупка, опять же стандартных, недорогих "торговых" программ. Они вписываются в развивающийся бизнес лишь частично и, поскольку не имеют возможностей подстройки, то подготавливают переход к полностью интегрированной настраиваемый системе - реальной АСУ. Посмотрим, с чем же подходит предприятие к этому построению. Во-первых, существуют какие-то технологии информационного обмена, успевшие войти в традицию. Например, ведется база клиентов в Access и управленческий финансовый учет в Excel. Что-то дублируется в бухгалтерскую программу, в основном, параллельным вводом, что-то хранится лишь в форме бумажных документов. Устоявшиеся привычки - самая проблемная область изменений, в которой всегда приходится ожидать ожесточенного сопротивления. Против коррекции существующего порядка будут выдвинуты десятки обоснованных аргументов: от соображений безопасности и конфиденциальности до экономичности и технологичности уже применяемых методов. (Часть, заслуживающая более серьезного внимания, - преемственность рыночной информации - обычно не озвучивается: структурированной рыночной информации на предприятии без АСУ нет). Во-вторых, существует баланс влияния, построенный на приоритетах предыдущей деятельности. Если главенствующим подразделением до сих пор была бухгалтерия (есть фирмы, где "хороший" баланс дажезаявляется главной целью), высока вероятность создания однобокой системы, решающей локальные неосновные задачи. Даже сбытовая ориентация, расширяя диапазон используемой информации, не обеспечивает его полное перекрытие, оставляя "за кадром" его маркетинговую или финансовую часть. В-третьих, возможности предприятия в построении АСУ ограничиваются финансами и сроками. Необходимость в интегрированной системе осознается руководителем на уровне "нужна вчера", а какие-то мощные финансовые вливания для ее разработки или покупки обычно нереальны. (Исключение составляют крупные постсоветские организации, перешедшие в руки частных владельцев, - в них эволюция идет собственным путем). В абсолютных цифрах, стоимость "приличной" покупной системы варьируется от десятков до сотен тысяч долларов, а квалифицированная собственная разработка выполняется за 6-12 месяцев. Итак, покупать или разрабатывать? В первом случае мы тратим, в основном, деньги, а не время, и получаем продукт заранее определенного качества. Эту оценку легко получить, если не ограничиваться уверениями поставщика, а проверить систему в действии на предприятиях, купивших ее ранее. Как минимум, отзыв пользователи дадут всегда. Покупная система будет играть роль стабилизатора: с одной стороны, она исправит слишком явные управленческие перекосы покупателя (приобрести стандартную систему, закрепляющую приоритет бухгалтерской отчетности в бизнесе, не удастся при всем желании); с другой, - снизит эффективность уникальных успешных технологий, ограничив их применение встроенными алгоритмами. Например, в части сопровождения бартерных операций стандартно успешных решений на рынке нет. Говорить об индивидуальной настройке системы можно, но надо иметь в виду, что ее стоимость возрастет в несколько раз. Таким образом, покупка готовой системы влечет за собой встречную перестройку бизнес-технологий по определенному образцу. С точки зрения стратегий, такая ситуация неперспективна, т.к. даже в случае эффекта оптимизации, полученного, при добросовестном внедрении сегодня, завтрашнее развитие потребует коррекции или смены системы. Мировая практика предлагает здесь абонентское обслуживание, но реально это полезно только крупным организациям, проводящим последовательную политику, и обладающим значительными средствами. Добавим еще, что покупка "суперхорошей" и сверхпроизводительной системы должна совершаться опытным пользователем, испытавшим программу предыдущей ступени и вышедшим за рамки ее возможностей. В противном случае, приобретается просто дорогая игрушка, которую невозможно применить с пользой. Типичным примером здесь может послужить одно российское пароходство, купившее АСУ за $2 млн., затратившее еще $500 тыс. на обучение персонала работе с ней, а теперь рассматривающее вопрос о собственной разработке системы. Если разрабатывать, то как? Прежде всего, оговоримся, что заявленные проблемы неоптимальности технологий никуда не уходят. Их все-равно придется решать, причем, без "правильного" образца. Возможным изменениям в приоритетах и философии бизнеса мы посвятили значительную часть книги, поэтому здесь просто изложим без аргументации логику взаимодействий:
АСУ является стратегическим инструментом управления и обладает приоритетом перед существующими технологиями, но подчиняется основным стратегиям предприятия. С этой точки зрения, до разработки следует определиться со стратегическо-целевым комплексом. Может возникнуть искушение решить разработкой АСУ сразу две задачи: приобрести систему себе и получить продукт для продажи на программном рынке. Эти задачи конфликтны, - программа "для себя" предназначена обслуживать уникальные технологии данного конкретного предприятия, программа "для других" должна быть стандартизована ради расширения круга возможных покупателей (при этом она теряет уникальность, не решает внутренних задач фирмы, ничем не выделяется на рынке). Попытка "убить двух зайцев" одной разработкой обычно заканчивается изготовлением программного полуфабриката. Но и "правильная" ориентация на единственную цель не обеспечит сама по себе нужного качества. Один из наиболее проблемных вопросов в создании АСУ - вопрос координатора проекта. Традиционно эта роль отводится руководителю группы программистов - предполагается, что именно он лучше способен увязать "простые и понятные" бизнес-процессы с алхимией компьютерных программ. Программисту, в любом случае, открыта вся информация, закладываемая в систему, назначение его координатором не расширяет круг "слишком осведомленных" людей. Чтобы оценить эффективность традиционного решения, следует рассмотреть логику построения АСУ под руководством программиста. Здесь типичны две альтернативы: 1. Программист получает от пользователей технические задания по отдельным блокам и бизнес-процессам (более или менее квалифицированное описание существующей практики, пожелания к форме таблиц и отчетности) и затем строит единую концепцию системы. 2. Программист реализует собственные идеи и наработки, подгоняя под них внутрифирменные технологии. Оба варианта имеют существенные недостатки. В первом случае будут узаконены все перекосы оргструктуры и управления, создан продукт, отвечающий формальным требованиям, но непригодный к использованию. (Например, в одной фирме менеджер сбыта должен был выполнить 131 операцию "мышкой", чтобы выписать покупателю счет из 5-ти позиций. При этом программа отвечала формальным требованиям ТЗ). Во втором случае будут воспроизведены технологические решения из прежнего опыта программиста, не обязательно эффективные для данного предприятия. Если рассматривать цели автоматизации шире, чем облегчение ручного счета и замену бумажной картотеки на электронную, целесообразно расширить и спектр основных задач координатора. Главной в этом ряду становится оптимизация управленческой системы - маркетинговой информации, планирования и контроля. Управление до и после разработки АСУ должно кардинально отличаться, иначе фирма изготовит себе микроскоп для забивания гвоздей. Таким образом, координатором должен выступать сильный управленец, возможно, привлеченный со стороны, обладающий широкими полномочиями, лидерскими качествами и определенным авторитетом. На нулевом этапе разработки определяются ее цели и концепция. Здесь приходится решать главный вопрос внедрения изменений: что приоритетно, тактика или стратегия? В любом деле достаточно легко предъявить яркие быстрые результаты, снимающие сиюминутные проблемы (например, красивый график приходов на дисплее руководителя), но кардинальные стратегические преимущества достигаются долгим кропотливым трудом. Если пренебречь формальным определением (и реальным согласованием) целей, велика вероятность отклонения разработки в сторону латания старых дыр и переформатирования отчетности. Однако особых проблем в целеопределении здесь не ожидается. На нулевом этапе руководители среднего звена обычно не представляют, насколько глубоки будут изменения, и как это скажется на их повседневной деятельности. Предложенные координатором цели принимаются в качестве базовых, с мыслью о возможной их коррекции в будущем. На самом деле, все дальнейшее уже определено концепцией программы, и вряд ли может быть серьезно скорректировано даже при обоюдном желании заказчика и программиста. Следующий основной этап разработки АСУ - формализация (алгоритмизация) бизнес-процессов. Уникальные эффективные технологии предприятия должны быть сохранены и усилены программной поддержкой, другие процедуры подлежат кардинальным изменениям. До внедрения интегрированной системы было бессмысленно накапливать гигабайты текущей рыночной информации на бумажных носителях из-за невозможности их обработки. С внедрением АСУ становится бессмысленно пренебрегать самопроизвольно поступающей информацией. Финансовый учет ранее стоило вести в Excel, с вводом системы - нерационально. Перемены затрагивают большинство функциональных областей предприятия, сверхзадачей этого этапа становится обеспечение рабочего взаимодействия группы программистов и носителей технологий в функциональных подразделениях. На практике, нужный уровень взаимодействия достигается только при отказе от действующих на предприятии формальных процедур. Попытки директивного распределения обязанностей и согласования ТЗ, написанных в подразделениях, моментально заводят в тупик - создание нового продукта по старым правилам проблематично. "Договаривающиеся стороны" знают каждая лишь часть нужной технологии, и должны разговаривать либо на одном техническом языке, либо практически постоянно. В нескольких случаях успешной разработки АСУ проблема решалась стихийно сложившейся рабочей группой, в которой каждый был заинтересован в конечном результате. (Интересно, что неформальные рабочие группы складываются и на проблемных предприятиях, наряду с бесполезными комитетами и комиссиями, в условиях конфликта персонала с авторитарным собственником). Если сопротивление среднего звена новшествам не удается преодолеть "в лоб", а новые технологии объективно необходимы, следует, по крайней мере, организовать хранение данных удобным для будущего развития системы образом. Практически невозможно решить разом все задачи, однако можно создать плацдарм для их решения в ближайшем будущем. Третьим этапом становится экспериментальная отработка новых алгоритмов. Как это ни сложно и трудоемко, все, что подлежит расчету через АСУ, должно быть хотя бы раз опробовано вручную. Смысл этой процедуры в устранении противоречий и несообразностей, которые обязательно присутствуют в любом тщательно составленном плане. Если эксперимент не проводить, впоследствии гораздо больше времени уйдет на устранение ошибок, либо программа просто не будет использована. "Раскачать" на проверку слабо заинтересованные отделы - одна из труднейших задач координатора проекта. Наконец, последний обязательный этап - полномасштабное обучение пользователей всем блокам системы. Множество полезных начинаний не реализуется до конца только потому, что рядовым исполнителям неясен их смысл. Любой менеджер понимает и готов самостоятельно освоить работу с частью программы, касающейся его лично. Но тот же ввод маркетинговой информации или прогноза сбыта в систему многим кажется прихотью начальства - до того, как они увидят практическое использование данных. Наиболее продуктивным здесь будет не обучение пользователей по подразделениям, а их объяснение друг-другу технологий использования АСУ в собственной практике. Таким образом, на каждый информационный блок появляется свой заказчик, обладающий личными характеристиками и местом в коллективе, и халтура при вводе данных будет означать не борьбу с формализмом и бюрократией, а "подставку" конкретного коллеги. Для максимального эффекта процедура обучения должна быть выделена в специальное действо (возможно, проводимое в выходной), и тщательно подготовлена. Докладчиками выступят наиболее квалифицированные пользователи в подразделениях (носители технологий), ответы на технические вопросы должен дать программист. Как уже отмечалось, процесс разработки охватывает длительный период, на протяжении которого меняется рыночная ситуация, стратегии организации, а значит, и задачи АСУ. Сама программа вводится в эксплуатацию функциональными блоками. Этапность построения при этом должна быть сохранена: цели и концепция программы - формализация бизнес-процессов - экспериментальная отработка - обучение. В противном случае, произойдет все то же тактическое отклонение в ущерб стратегиям, на каком-то этапе система не сможет развиваться. Эта опасность сохраняется и после разработки, когда функциональные блоки постоянно "доводятся" под эволюционирующие бизнес-технологии. Чтобы свести риск к минимуму, целесообразно раз в пол года - год заново рассматривать эффективность АСУ, используя для этого стандартные процедуры ревизии маркетинга, управленческой диагностики с помощью привлеченного консультанта или специально назначенного менеджера проекта. |
||