Корпоративная автоматизированная информационная
система как ресурс бизнеса (как поставить ИТ на службу бизнеса?)
Сергей Цодиков,
генеральный директор группы компаний «Форус»
Использование
потенциала ИТ как стратегического ресурса бизнеса – вряд ли кто-то сегодня
будет спорить с важностью этого утверждения. Для серьезных фирм – внедренцев ИТ
решений оно стало почти определяющим лозунгом во взаимоотношениях с
потенциальным заказчиком. Но как реализуется этот потенциал в реальных
проектах?
Многолетний
опыт внедрения бизнес приложений позволяет констатировать – при проектировании
автоматизированной информационной системы (АИС) участники проекта, как правило,
ориентируются на решении операционных проблем бизнеса. Заказчик не настаивает
на включение в проект стратегических бизнес - требований, а проектировщик не
формулирует постановку задачи как стратегическое бизнес-решение. Под словами
«стратегическое решение» мы понимаем корпоративное информационное решение,
ориентированное на получение устойчивого конкурентного преимущества бизнеса
заказчика.
В
результате, потенциал АИС как стратегического ресурса бизнеса декларируется, но
не реализуется в проекте автоматизации. При этом, о наличии такого потенциала
заявляет всякий уважающий себя разработчик АИС. Очевидно, что добиться
реализации потенциала АИС как ресурса бизнеса весьма непросто. Не претендуя на
полноту анализа, попытаемся определить некоторые «болевые» точки проекта АИС,
ориентированного на стратегические задачи.
Очевидно,
что «стратегический» потенциал закладывается на первой стадии разработки
решения – при постановке задачи. Отсюда следует, что именно она требует самого
пристального внимания. Как известно, на этой стадии происходит системное
описание бизнес – задачи - определяются и фиксируются ключевые факторы проекта:
цели, критерии выполнения, рамки проекта, описание его результата. Однако опыт
участия в качестве исполнителя проектов свидетельствует о том, что решение
бизнес задач и их автоматизация существуют как бы в разных плоскостях: бизнес
сам по себе, а АИС – сама по себе. На наш взгляд, в этой рассогласованности и
кроется главная причина недооценки потенциала АИС как ресурса бизнеса.
Скажите,
можно ли назвать разумной причиной построения АИС ПРОЦЕСС автоматизации
бизнеса? Вряд ли, разве что из бескорыстной любви руководителя к ПРОЦЕССУ
автоматизации или как дани к моде. Рациональной причиной применения АИС в
бизнесе является НЕОБХОДИМОСТЬ РЕШЕНИЯ бизнес задач. Понимает ли это до конца
заказчик, а зачастую и исполнитель проекта автоматизации? Судите сами. Вот
типичные выдержки из опросов руководителей по постановке задачи и определению
целей проекта построения АИС, которые систематически проводятся отделом
маркетинга нашей компании:
1)
Директор региональной компании: «Мне нужно, чтобы необходимая мне информация
была всегда под рукой. Желательно, чтобы количество ее разрезов было
максимальным». Попытка уточнения целей приводила к ответам: «Я в информационных
технологиях ничего не понимаю, Вы - «информационщики», Вам и карты в руки. А
мне надо, чтобы у меня было все хорошо с информацией: она должна быть
своевременна, точна и полна! Сделайте это для меня».
2)
Директор крупной столичной оптовой компании: «У меня постоянная проблема с
приемом заказов – не вижу я обеспеченность заказа товарной продукцией. Хорошо
бы знать - где и какой товар находится: на складе, зарезервирован под заказ и
на какой срок, в пути, в комплектации. Вот если бы я знал это, у меня не было
бы проблем. Это и есть суть нашего заказа на разработку АИС».
3)
Директор производственной компании: «Мы заложили деньги в бюджет на ИТ. Идите к
бухгалтеру/директору по ИТ – он/они Вам все расскажет».
При
этом во всех случаях вопрос о необходимости внедрения непременно САМОЙ
СОВРЕМЕННОЙ АИС под сомнение не ставился.
О
чем говорят эти примеры? В первом варианте произошла подмена целей построения
АИС характеристиками информации. Исполнителю проекта предлагается самому сформулировать
цели построения АИС, что означает в данном случае, ни много не мало -
сформулировать цели бизнеса заказчика. Не правда ли парадоксальная ситуация?
Неуспех проекта просто запрограммирован.
В
третьем случае цели бизнеса подменяются частичными и главное, обеспечивающими
целями функциональных подразделений. Вопрос в том, знают ли они цели бизнеса?
Деньги будут потрачены с высоким уровнем контроля, вот только под какой
разумный бизнес-результат?
Второй
пример выглядит на первый взгляд определеннее остальных. Но, по сути, он
представляет завуалированную разновидность третьего случая. В нем ключевой
задачей объявляется контрольная функция АИС. Вряд ли ее можно назвать целью
бизнеса. Тем не менее, закрепив цели проекта в контракте, проект получает право
на существование, реализуется и объявляется успешным. Другими словами, заказчик
эффективно потратил деньги. При этом из виду упущено, что первичной целью
бизнеса является не трата, пусть и эффективная, а ЗАРАБАТЫВАНИЕ денег.
Итак,
ключевая проблема успешного проекта АИС состоит в том, как заказчик понимает
этот проект: как затратный или как инвестиционный. Многолетний опыт работы
показывает, что только 4 - 5 %% руководителей ставят перед проектом внедрения
АИС по настоящему инвестиционные задачи. Другими словами, необходимым условием
успешности проекта АИС должно стать его нацеленность на конечные, а не
промежуточные цели и результаты бизнеса.
И
вот здесь начинается самое интересное. При попытке прояснить цели бизнеса,
разговор с руководителем компании до боли напоминает аллегорический диалог
Алисы и Чеширского кота из книги Льиса Кэрролла «Алиса в стране чудес»:
«
- Скажите пожалуйста, куда мне отсюда идти? – спросила Алиса.
-
А куда ты хочешь попасть? – ответил Кот.
-
Мне все равно… - сказала Алиса.
-
Тогда все равно, куда и идти – заметил Кот».
К
сожалению, из нашей практики, значительное количество компаний пытаются достичь
результатов, не имея четкого представления о том, какими они должны быть. Таким
образом, выявление и четкая формулировка цели бизнес деятельности и АИС как
одного из ресурсов ее достижения является критической задачей первой фазы
проекта АИС. Но как ее выявить? Очевидно, для этого требуется:
1.
Доступ разработчиков АИС к высшему руководству компании заказчика, которое
потенциально является «носителем» знания о целях и реальных проблемах своего
бизнеса.
2.
Наличием у разработчика АИС специалистов, компетенций и технологии выявления и
формулировки бизнес задач заказчика. Эти специалисты должны владеть не только
знаниями и навыками системного анализа, но и уметь ставить и анализировать
бизнес – задачи на языке бизнеса. Действительно, даже если вам удается получить
доступ к руководству компании заказчика, не стоит особенно надеяться на то, что
оно сумеет сразу дать вам ясные и понятные разъяснения целей компании.
Выявление этих целей является итерационным процессом, требующим нетривиальных
усилий, специальных знаний и применения специальной техники по выработке
согласованного видения решаемой задачи у участников проекта АИС.
3.
Компетентность разработчика АИС – его способность переводить бизнес – задачи в
цели проекта АИС.
Следует
отметить, что существующая теория проектирования АИС, хотя и подчеркивает
важность фазы выявления требований к АИС, исходит из предположения, что цели,
желаемое состояние объекта автоматизации, а значит - требования к АИС, известны
заказчику до начала проекта. Разработчику необходимо сформулировать,
зафиксировать и одобрить их у заказчика в ходе системно-аналитического
обследования предприятия. Это положение закрепляется как базовое во всех
учебных программах по подготовке АИС специалистов. Оно выступает как некий
водораздел между бизнес - и ИТ консалтингом. И потому, что его «так учили и так
положено», разработчик АИС ведет себя в соответствие с принципом «чего
изволите», выполняя АИС проект так, как будто участники выработали
согласованное, точное и определенное понимание его целей. И разработчик АИС
проводит опросы, выявляет и анализирует требования заказчика, которые с высокой
вероятностью не отвечают его бизнес целям. Не здесь ли лежат причины
скептических замечаний части топ менеджмента о бесполезности АИС, о нечестных и
корыстных информационщиках, только и думающих о том, как бы побольше заработать
на плохо разбирающихся в особенностях информационных технологий руководителях?
При
выполнении проекта построения корпоративной АИС в нашей практике принято
исходить из другой посылки: цели АИС проекта следует обязательным образом
выявлять и согласовывать с заказчиком. Причем исключительно в контексте бизнес
целей предприятия заказчика. Мы исходим из принципа, что гораздо важнее не то,
как утверждает теория проектирования АИС, а то, что правильно и работает на
практике.
Проиллюстрируем
подход и оценим его результативность на примере внедрения АИС для одного из наших
заказчиков.
Руководитель
ИТ службы заказчика выступил инициатором проекта автоматизации подразделения
экспедиции хлебокомбината. В его трактовке проблема, требующая
автоматизированного решения, заключалась в невысокой скорости обработки
транзакций существующей АИС в операциях отпуска хлеба оптовым потребителям. Это
приводило к тому, что, служба экспедиции не могла оперативно отслеживать
остатки хлеба по сортам в процессе отгрузки. Работая «вслепую», служба
разрешала отгрузку хлеба, зарезервированного под гарантированные заказы:
детские сады, школы и т.д. Побочным эффектом являлась низкая скорость
обслуживания: машины потребителей занимали очередь с 5 –ти утра, а обслуживание
занимало много времени.
В
соответствие с заявленной целью, нами было сделано технико-коммерческое
предложение по разработке и внедрению АИС, позволяющее ускорить работу
существующей АИС в 3 раза. Включение в процесс переговоров с коммерческим
директором формально о стоимости и сроках исполнения проекта бизнес –
консультанта, применившего технологию процессного консалтинга, позволило по
иному увидеть цели построения АИС. В ходе переговоров бизнес – консультанту
удалось выяснить, что ключевой бизнес - задачей предприятия являлось
установление оптимальных издержек производства хлеба. Задействуя три печи по
производству хлеба (полная мощность), завод обеспечивал хлебом всех желающих
потребителей, но имел высокий уровень возврата черствого хлеба через свои
розничные точки. При использовании двух печей появлялся дефицит хлеба.
Выявленная
проблема привела к переформулировке первоначальной цели проекта автоматизации.
Целью стала разработка не транзакционной, а аналитической АИС по выявлению и
мониторингу целевых клиентов и их потребностей. Задачи были сформулированы как
анализ состава клиентов, структуры заказа и определение уровней обслуживания
потребителей. Аналитическая АИС позволила установить такой факт: из более чем
500 оптовых потребителей, 80 % объема сбыта в денежном выражении обеспечивали
не более 120 из них. При этом и объем, и структура потребностей этих клиентов
хорошо коррелировали с мощностями двух, а не трех печей. В целом, проект
разработки аналитической АИС переориентировался на достижение бизнес целей:
фокусе на целевых потребителях и номенклатуре выпускаемой продукции, соответствующей
потребностям целевых потребителей. Реализация проекта привела к сокращению
уровня издержек и потерь при улучшении уровня обслуживания целевых клиентов,
список которых был выявлен, а их обслуживание организовывалось в приоритетном
порядке. Описанный пример показывает, как путем уточнения на стадии постановки
целей удается добиться превращения АИС в эффективный ресурс бизнеса.
Таким
образом, процессный консультант еще до начала проекта АИС, вместе с заказчиком
должен четко и ясно сформулировать ответы на такие «простые» вопросы:
-
Каково существующее положение бизнеса заказчика?
-
Каковы направления движется бизнеса и их приоритетность?
-
Чем обосновываются выбранные приоритеты?
-
Каково желаемое состояние и цели бизнеса?
-
Какие задачи следует решить, чтобы добиться желаемого состояния?
-
Каковы порядок решения задач и критерии, сигнализирующие, что решение
достигнуто?
-
Что следует делать следующим шагом?
-
Полученные совместно с заказчиком ответы и позволяют сформировать согласованное
видение целей, задач, критериев проекта. Они образуют своеобразную путеводную
нить в успешном проекте построения АИС, нацеленном на повышение эффективности
бизнеса.
В
заключении подчеркнем еще раз, что для реализации описанного подхода
разработчик должен иметь технологические компетенции и навыки, умение
эффективно организовать взаимодействие с клиентом, обладать проверенной
технологией и дисциплиной выполнения проекта. Именно поэтому в компании
"Форус" уделяется максимальное внимание разработке и постоянному
совершенствованию технологии процессного консультирования, формированию
компетенций в ИТ- и бизнес – консалтинге, условий реализации этой технологии в
проектной практике.
Список литературы
Друкер
П. Задачи менеджмента в ХХI веке. – М.: Издательский дом «Вильямс», 2000.
Гейтс
Б. Бизнес со скоростью мысли. – М.: Из-во ЭКСМО-Пресс, 2001.
Кэрролл
Л. Алиса в стране чудес. – М.:Наука, 1990.
Уилсон
С., Мэйплс Б., Лэндгрейв Т. Принципы проектирования и разработки программного
обеспечения. – М.: Издательско-торговый дом «Русская Редакция», 2000.
Kendall K, Kendall J. Systems
Analysis and Design. – New Jersey: Prentice – Hall, Inc., 1988.