Сергей Цодиков, генеральный директор группы компаний «Форус»
Использование потенциала ИТ как стратегического ресурса бизнеса – вряд ли кто-то сегодня будет спорить с важностью этого утверждения. Для серьезных фирм – внедренцев ИТ решений оно стало почти определяющим лозунгом во взаимоотношениях с потенциальным заказчиком. Но как реализуется этот потенциал в реальных проектах?
Многолетний опыт внедрения бизнес приложений позволяет констатировать – при проектировании автоматизированной информационной системы (АИС) участники проекта, как правило, ориентируются на решении операционных проблем бизнеса. Заказчик не настаивает на включение в проект стратегических бизнес - требований, а проектировщик не формулирует постановку задачи как стратегическое бизнес-решение. Под словами «стратегическое решение» мы понимаем корпоративное информационное решение, ориентированное на получение устойчивого конкурентного преимущества бизнеса заказчика.
В результате, потенциал АИС как стратегического ресурса бизнеса декларируется, но не реализуется в проекте автоматизации. При этом, о наличии такого потенциала заявляет всякий уважающий себя разработчик АИС. Очевидно, что добиться реализации потенциала АИС как ресурса бизнеса весьма непросто. Не претендуя на полноту анализа, попытаемся определить некоторые «болевые» точки проекта АИС, ориентированного на стратегические задачи.
Очевидно, что «стратегический» потенциал закладывается на первой стадии разработки решения – при постановке задачи. Отсюда следует, что именно она требует самого пристального внимания. Как известно, на этой стадии происходит системное описание бизнес – задачи - определяются и фиксируются ключевые факторы проекта: цели, критерии выполнения, рамки проекта, описание его результата. Однако опыт участия в качестве исполнителя проектов свидетельствует о том, что решение бизнес задач и их автоматизация существуют как бы в разных плоскостях: бизнес сам по себе, а АИС – сама по себе. На наш взгляд, в этой рассогласованности и кроется главная причина недооценки потенциала АИС как ресурса бизнеса.
Скажите, можно ли назвать разумной причиной построения АИС ПРОЦЕСС автоматизации бизнеса? Вряд ли, разве что из бескорыстной любви руководителя к ПРОЦЕССУ автоматизации или как дани к моде. Рациональной причиной применения АИС в бизнесе является НЕОБХОДИМОСТЬ РЕШЕНИЯ бизнес задач. Понимает ли это до конца заказчик, а зачастую и исполнитель проекта автоматизации? Судите сами. Вот типичные выдержки из опросов руководителей по постановке задачи и определению целей проекта построения АИС, которые систематически проводятся отделом маркетинга нашей компании:
1) Директор региональной компании: «Мне нужно, чтобы необходимая мне информация была всегда под рукой. Желательно, чтобы количество ее разрезов было максимальным». Попытка уточнения целей приводила к ответам: «Я в информационных технологиях ничего не понимаю, Вы - «информационщики», Вам и карты в руки. А мне надо, чтобы у меня было все хорошо с информацией: она должна быть своевременна, точна и полна! Сделайте это для меня».
2) Директор крупной столичной оптовой компании: «У меня постоянная проблема с приемом заказов – не вижу я обеспеченность заказа товарной продукцией. Хорошо бы знать - где и какой товар находится: на складе, зарезервирован под заказ и на какой срок, в пути, в комплектации. Вот если бы я знал это, у меня не было бы проблем. Это и есть суть нашего заказа на разработку АИС».
3) Директор производственной компании: «Мы заложили деньги в бюджет на ИТ. Идите к бухгалтеру/директору по ИТ – он/они Вам все расскажет».
При этом во всех случаях вопрос о необходимости внедрения непременно САМОЙ СОВРЕМЕННОЙ АИС под сомнение не ставился.
О чем говорят эти примеры? В первом варианте произошла подмена целей построения АИС характеристиками информации. Исполнителю проекта предлагается самому сформулировать цели построения АИС, что означает в данном случае, ни много не мало - сформулировать цели бизнеса заказчика. Не правда ли парадоксальная ситуация? Неуспех проекта просто запрограммирован.
В третьем случае цели бизнеса подменяются частичными и главное, обеспечивающими целями функциональных подразделений. Вопрос в том, знают ли они цели бизнеса? Деньги будут потрачены с высоким уровнем контроля, вот только под какой разумный бизнес-результат?
Второй пример выглядит на первый взгляд определеннее остальных. Но, по сути, он представляет завуалированную разновидность третьего случая. В нем ключевой задачей объявляется контрольная функция АИС. Вряд ли ее можно назвать целью бизнеса. Тем не менее, закрепив цели проекта в контракте, проект получает право на существование, реализуется и объявляется успешным. Другими словами, заказчик эффективно потратил деньги. При этом из виду упущено, что первичной целью бизнеса является не трата, пусть и эффективная, а ЗАРАБАТЫВАНИЕ денег.
Итак, ключевая проблема успешного проекта АИС состоит в том, как заказчик понимает этот проект: как затратный или как инвестиционный. Многолетний опыт работы показывает, что только 4 - 5 %% руководителей ставят перед проектом внедрения АИС по настоящему инвестиционные задачи. Другими словами, необходимым условием успешности проекта АИС должно стать его нацеленность на конечные, а не промежуточные цели и результаты бизнеса.
И вот здесь начинается самое интересное. При попытке прояснить цели бизнеса, разговор с руководителем компании до боли напоминает аллегорический диалог Алисы и Чеширского кота из книги Льиса Кэрролла «Алиса в стране чудес»:
« - Скажите пожалуйста, куда мне отсюда идти? – спросила Алиса.
- А куда ты хочешь попасть? – ответил Кот.
- Мне все равно… - сказала Алиса.
- Тогда все равно, куда и идти – заметил Кот».
К сожалению, из нашей практики, значительное количество компаний пытаются достичь результатов, не имея четкого представления о том, какими они должны быть. Таким образом, выявление и четкая формулировка цели бизнес деятельности и АИС как одного из ресурсов ее достижения является критической задачей первой фазы проекта АИС. Но как ее выявить? Очевидно, для этого требуется:
1. Доступ разработчиков АИС к высшему руководству компании заказчика, которое потенциально является «носителем» знания о целях и реальных проблемах своего бизнеса.
2. Наличием у разработчика АИС специалистов, компетенций и технологии выявления и формулировки бизнес задач заказчика. Эти специалисты должны владеть не только знаниями и навыками системного анализа, но и уметь ставить и анализировать бизнес – задачи на языке бизнеса. Действительно, даже если вам удается получить доступ к руководству компании заказчика, не стоит особенно надеяться на то, что оно сумеет сразу дать вам ясные и понятные разъяснения целей компании. Выявление этих целей является итерационным процессом, требующим нетривиальных усилий, специальных знаний и применения специальной техники по выработке согласованного видения решаемой задачи у участников проекта АИС.
3. Компетентность разработчика АИС – его способность переводить бизнес – задачи в цели проекта АИС.
Следует отметить, что существующая теория проектирования АИС, хотя и подчеркивает важность фазы выявления требований к АИС, исходит из предположения, что цели, желаемое состояние объекта автоматизации, а значит - требования к АИС, известны заказчику до начала проекта. Разработчику необходимо сформулировать, зафиксировать и одобрить их у заказчика в ходе системно-аналитического обследования предприятия. Это положение закрепляется как базовое во всех учебных программах по подготовке АИС специалистов. Оно выступает как некий водораздел между бизнес - и ИТ консалтингом. И потому, что его «так учили и так положено», разработчик АИС ведет себя в соответствие с принципом «чего изволите», выполняя АИС проект так, как будто участники выработали согласованное, точное и определенное понимание его целей. И разработчик АИС проводит опросы, выявляет и анализирует требования заказчика, которые с высокой вероятностью не отвечают его бизнес целям. Не здесь ли лежат причины скептических замечаний части топ менеджмента о бесполезности АИС, о нечестных и корыстных информационщиках, только и думающих о том, как бы побольше заработать на плохо разбирающихся в особенностях информационных технологий руководителях?
При выполнении проекта построения корпоративной АИС в нашей практике принято исходить из другой посылки: цели АИС проекта следует обязательным образом выявлять и согласовывать с заказчиком. Причем исключительно в контексте бизнес целей предприятия заказчика. Мы исходим из принципа, что гораздо важнее не то, как утверждает теория проектирования АИС, а то, что правильно и работает на практике.
Проиллюстрируем подход и оценим его результативность на примере внедрения АИС для одного из наших заказчиков.
Руководитель ИТ службы заказчика выступил инициатором проекта автоматизации подразделения экспедиции хлебокомбината. В его трактовке проблема, требующая автоматизированного решения, заключалась в невысокой скорости обработки транзакций существующей АИС в операциях отпуска хлеба оптовым потребителям. Это приводило к тому, что, служба экспедиции не могла оперативно отслеживать остатки хлеба по сортам в процессе отгрузки. Работая «вслепую», служба разрешала отгрузку хлеба, зарезервированного под гарантированные заказы: детские сады, школы и т.д. Побочным эффектом являлась низкая скорость обслуживания: машины потребителей занимали очередь с 5 –ти утра, а обслуживание занимало много времени.
В соответствие с заявленной целью, нами было сделано технико-коммерческое предложение по разработке и внедрению АИС, позволяющее ускорить работу существующей АИС в 3 раза. Включение в процесс переговоров с коммерческим директором формально о стоимости и сроках исполнения проекта бизнес – консультанта, применившего технологию процессного консалтинга, позволило по иному увидеть цели построения АИС. В ходе переговоров бизнес – консультанту удалось выяснить, что ключевой бизнес - задачей предприятия являлось установление оптимальных издержек производства хлеба. Задействуя три печи по производству хлеба (полная мощность), завод обеспечивал хлебом всех желающих потребителей, но имел высокий уровень возврата черствого хлеба через свои розничные точки. При использовании двух печей появлялся дефицит хлеба.