CC BY
38
В статье обобщается опыт последних лет работы на проектах по выбору корпоративной информационной системы (КИС), проводимых консультационной компанией МСТ lab. Автор адресует ее тем, перед кем стоит или в близком будущем встанет задача выбора масштабной КИС для организации, и кто будет отвечать за успех этого решения. Рассматриваются изменения, которые произошли в бизнесе и в самих информационных технологиях, даются практические рекомендации
Сергей МУРАТОВ.
генеральный директор консалтинговой компании МСТ lab ([email protected])
ак бы ни хотелось нам избегать перемен, жить без них невозможно. Все зависит от отношения к ним. Для кого-то перемены — это новая волна, оседлав которую можно достичь иных высот, для кого-то — шторм, от которого надо укрыться.
Кризис, который изменил современную парадигму рынка, служит явным доказательством того, что перемены происходят несмотря ни на что. Предлагаемая статья — о переменах в области выбора программного обеспечения. Скажу больше: нельзя выбирать КИС1 по-старому.
Суть произошедших перемен
Организации меняются быстрее, чем хотелось бы
Растут темпы перемен в бизнесе. Период, в течение которого предприятия остаются неизменными, постоянно сокращается. Раньше можно бы-
ло спокойно проработать в компании 10 лет, и она оставалась той же. Сейчас уже говорят о 3—5 годах, в течение которых бизнес-процессы и организационная структура предприятия скорее всего претерпят изменения.
Это приводит к очевидному несоответствию между временными рамками «периода стабильности» и сроками ИТ-проектов, таких как внедрение (включая и стадию выбора) ERP-систем, требующих не менее 2—3 лет при достаточно структурированных и стандартных процессах. Организации как объект автоматизации меняются быстрее, чем мы успеваем внедрить крупную систему. Если же изменения касаются интеграции с другими системами и требуют доработок под специфические потребности заказчика, то проекты могут быть гораздо более продолжительными по времени.
Вспоминается описанный в литературе случай. Одна крупная органи-
Под понятием «корпоративная информационная система» (КИС) в статье объединяется широкий класс систем для бизнеса, включая ERP и другие системы.
Эволюция роли ИТ как преобразующей силы бизнеса (по материалам Gartner Group)
Упростить
+Создать новоеРазвитие \\Новые источник дохода бизнеса 'стимулируется ИТ4
+Улучшить // '^Преимущества
Учет интересов участников бизнеса
+Оптимизировать
Эффективность и стабильность
Цели
Уровень развития
Результаты
Рис. 1
зация, проводя анализ требований и масштабное описание бизнес-процессов для предстоящего проекта автоматизации, столкнулась с ситуацией, когда изменения происходили с тем же темпом, с которым группа внедрения актуализировала документацию, описывающую бизнес-процессы. На третий(!) год руководство организации приняло решение остановить проект, так как в рамках выбранного подхода было невозможно начать внедрение.
Итак, еще 10 лет назад темп изменений был ниже, и проблема не была столь заметна. Изменения в окружающей среде все чаще происходят скорее, чем организация способна отреагировать. Это и является причиной того, что время, требующееся для перехода на новые бизнес-процессы и реализации бизнес-стратегии, становится новым «узким местом».
Современная ситуация требует, чтобы процесс предпроектного выбора (от старта до заключения договора с интегратором) занимал не более 6 месяцев, а лучше 4 месяца. В противном случае результаты анализа начинают устаревать, что приводит к неверному выбору.
Рост сложности ИТ-систем
Вернемся в недалекое прошлое. При покупке программ часто можно было услышать: «Дайте нам демоверсию, мы попробуем и, если понравится, то купим». Сейчас ничего подобного уже не происходит. Корпоративные системы стали настолько сложными, что пытаться изучить их, а тем более сравнить, стало абсолютно нереальной задачей.
Вспомним еще одно явление, отошедшее в прошлое. Раньше некоторые консультационные компании для облегчения выбора выпускали отчеты и электронные диски, содержащие сведения о программных продуктах. Теперь их не стало. И вот объяснение, почему.
Возьмем крупнейшую корпоративную систему - SAP ERP (SAP R/3). Внутри самой компании консультанты, занимающиеся внедрением, знают только 1—2 модуля этой системы. И то после нескольких лет работы в компании. Очевидно, что за время, отведенное на выбор, заказчик не может изучить систему, состоящую из нескольких модулей. А перед ним стоит еще более сложная задача - сравнить несколько систем.
Наблюдается рост сложности технологических решений, возникает необходимость интеграции множества технологий для обеспечения растущих потребностей бизнеса, государства и общества в целом. С каждым годом люди в своей повседневной деятельности все больше
полагаются на технологии. Такая сложность зачастую приводит к катастрофическому росту неудачных проектов внедрения информационных систем. Сегодня примерно половина ИТ-проектов в различных отраслях заканчиваются не так, как было запланировано, а в государственном секторе этот показатель достигает 70%.
Рост сложности ИТ-систем делает невозможным их сколько-нибудь надежное сравнение при выборе старым методом прямого изучения -для того чтобы добиться адекватного качества анализа просто не хватит времени.
Изменение роли ИТ-систем в бизнесе
За последние годы произошла ускоренная эволюция роли информационных технологий в бизнесе. Так, первоначально применение ИТ в основном сводилось к автоматизации отдельных операций, гораздо реже -ключевых служб или подразделений. Теперь же дело не ограничивается простым учетом транзакций, речь идет а о максимальном использовании функционала ИТ, без которого на данный момент практически невозможно организовать перспективный бизнес.
Таким образом за пару десятилетий роль ИТ в бизнесе сместилась от автоматизации рутинных операций к преобразованию всей модели ведения бизнеса (рис. 1).
В эпоху «кусочной» автоматизации ИТ следовали за развитием предприятия. При этом говорить о каком-то существенном влиянии технологий на бизнес не приходилось -они чаще всего или ускоряли, или удешевляли существующие функции. Сейчас картина меняется: ИТ-под-разделение замыкается на бизнес и делает его зависимым от ИТ. Это единственная функция, которая оказывает влияние на саму природу биз-
неса и возможность технологических изменений и способна влиять на стратегию предприятия. Как следствие на первый план постепенно выходит возможность изменения самого бизнеса, его рабочих процессов за счет внедрения ИТ, глубоко проникших в деятельность организации.
Такое изменение роли ИТ, появление у них качеств, способных преобразовывать процессы, делает задачу выбора ИТ-системы исключительно с точки зрения технологий невозможной.
Изменение роли не-ИТ-менеджмента в проекте выбора
С предыдущим пунктом тесно связана проблема оценки эффекта от возможного применения систем.
Нет нужды говорить, насколько такая оценка важна при их выборе.
Управленцы и бизнесмены мыслят в категориях бизнес-моделей, бизнес-процессов и специфических функций бизнеса, в то время как сотрудники ИТ-служб оперируют технологиями и техническими аспектами. Так было.
ИТ-системы долгое время рассматривались как «умная часть компьютеров». Вполне естественно, что корпоративная информационная система долго считалась исключительно прерогативой ИТ-служб, так как только их специалисты обладали соответствующей квалификацией и опытом.
Однако сейчас чтобы реально получить отдачу от проекта внедрения КИС, необходимо синтезировать опыт и знания бизнеса и ИТ, причем обе стороны должны быть заинтересованы в подобном сотрудничестве. К примеру, возможность сокращения персонала вследствие внедрения информационной системы рассматривается как потенциальное улучшение. Преимущества,
Май-июнь 2009 г. 49
I_Рис. 2 Средняя доля капиталь-
ных затрат на ИТ по отношению к суммарным капитальным затратам
которые организация получает от такого уменьшения трудозатрат, зависит от менеджеров2, которые решают, урезать ли фонд заработной платы организации в результате сокращения персонала или переместить часть освободившихся сотрудников в службы по работе с клиентами - тем самым улучшить их обслуживание.
ИТ обеспечивают потенциальные преимущества, но воплотить их в жизнь можно только при активном участии менеджмента. Соответственно, потребность в серьезном вовлечении руководства бизнеса в процесс выбора систем является тем изменением, которое необходимо принять всем - и ИТ, и бизнесу3.
Рост «цены вопроса» и «цены ошибки»
Еще одним важным фактором, определяющим актуальность новых, более систематических подходов к планированию и выбору ИТ, является постоянное увеличение расходов на информационные технологии и рост связанный с этим цены ошибки.
Достаточно репрезентативна зависимость капитальных расходов на ИТ, отнесенных к общим капитальным расходам компании. Эта зависимость имеет явную тенденцию к увеличению, так что прогнозируемая доля расходов на ИТ достигнет к 2015 г. почти половины совокупных капитальных затрат (рис. 2).
Хорошо известна история с одновременным внедрением на предприятиях Hershey Foods нескольких ERP-систем: когда после того как корпорация потратила более 100 млн долл. на консультантов, программное обеспечение и переобучение своих работников, оказалось, что установленная система по-прежнему не способна выполнять заяв-
ленные функции. Более того, кроме денег, потраченных на установку системы, компания начала терять доходы из-за того, что чехарда с программным обеспечением и ошибки новых пакетов привели к хаосу в логистике.
Есть примеры и поближе. Компания «Альфа Страхование» при выборе системы определила требования к ней. Но после начала проекта отсутствие всего одного требования в списке из нескольких сотен критериев чуть не привело к дополнительным расходам в 100 тыс. долл. — именно в такую сумму интегратор оценил доработку системы.
Таким образом выбор КИС — это полноценный инвестиционный проект, требующий серьезной профессиональной проработки. Не каждый сотрудник планового-экономическо-го отдела может подготовить обоснование инвестиционного проекта, а сотрудник ИТ-отдела — реализовать современный проект выбора систем.
Итак, нужен иной подход.
Новые правила выбора систем
Конечно, одна статья не может подготовить специалиста к проведению проекта выбора системы в новых условиях. Однако вполне может вооружить его некоторыми идеями и практическими подходами.
От проекта «познавательного» к проекту коммуникативному
Проект по выбору КИС в любом случае потребует изучения и анализа, но старый подход, в основе которого лежит изучение систем, более не применим. В основу нового подхода положены следующие факты из рассмотренных выше:
^ в рамках проекта выбора заказчик не имеет физической возможности сравнить системы на основе их прямого изучения;
^ выбор корпоративных систем не может оставаться делом только ИТ-специалистов, поскольку системы больше чем ранее стали влиять на рабочие бизнес-процессы. В оценке систем необходимо мнение бизнеса.
Здесь уместно заметить, что указанные перемены не обошли стороной и интеграторов: изучить все бизнес-требования заказчика на этапе продажи поставщик не в состоянии, поэтому наивно предполагать, что поставщик может сам оценить и четко обосновать необходимые трудозатраты по доработке системы на основании переговоров. Следова-
тельно, если заказчик не будет помогать поставщику в определении объемов работ, поставщик вряд ли сможет оценить финальную стоимость проекта.
Предлагаемая методика оставляет каждого в рамках своей компетенции: бизнес отвечает за свои бизнес-требования, а поставщик — за свои возможности. Фокус методологии заключается в организации правильной коммуникации между бизнесом и поставщиком, чтобы никому из них не надо было выходить за рамки своей компетенции и тратить время на выполнение заведомо невыполнимых задач.
Добиться этого можно путем обмена соответствующими документами, части которых готовятся разными специалистами, а сводная информация пригодна для формального анализа. Поясним эту идею.
Сбор требований для выбора системы отличается от сбора требований для разработки системы. Разница в том, что при разработке системы архитектор может задать такую архитектуру, какую считает нужной. Например, если заказчики и поставщики будут рассматриваться архитектором как разные сущности, то тогда в системе будут две отдельные таблицы, в одной из которых будут регистрироваться поставщики, а в другой - заказчики. Другой архитектор скажет, что поставщики и покупатели — это проявление одной общей сущности — «контрагент», который может иметь признак покупателя, поставщика или того и другого одновременно. Получить сводный отчет по операциям с контрагентами у второго разработчика будет гораздо проще. Для первой системы придется написать дополнительную логику, где, допустим, будет прописано, что поставщик с кодом 487 для отчета равен покупателю с кодом 118. Поэтому сначала надо собрать все операции с кодом 487 и все операции с кодом 118 в один отчет, а после этого рассчитать сальдо по расчетам с данным контрагентом.
Иными словами, при разработке системы должно приниматься решение о том, как будет выглядеть архитектура системы. В случае же выбора системы компания сталкивается с готовой архитектурой, с определенным набором решений. Например, пусть в некой системе сущности «поставщик» и «заказчик» определяются как разные сущности, но внедренец разработал механизм, объединяющий их, то есть
2 К сожалению, на данный момент мы часто вынуждены констатировать, что руководители бизнес-направлений не играют лидирующей роли в применении ИТ, а ИТ-департамент не занимается популяризацией новых технологий.
3 Далее под «ИТ» и «бизнесом» мы будем иметь в виду соответственно руководителей ИТ-службы на предприятии и руководителей других производственных функций, занятых в основной бизнес-деятельности предприятия.
Направление изменения бизнес-процессов и ИТ-обеспечения в увязке со стратегией предприятия
Рис. 3
доработал систему. Он создал некоторую надстройку, позволяющую обходить ограничения, связанные с разделением.
Когда определяются требования для выбора системы, не нужно вторгаться в область создания архитектуры. Нужно остановиться на тех вопросах, которые отражают деятельность компании и сообщают потенциальному поставщику о том, какая информация нужна в отчетах и учет каких операций нужно предусмотреть в системе. Выбор ведется уже в отношении системы и организованной в ней архитектуры. Поставщик соотносит деловые требования заказчика с теми вариантами, которые есть в его системе, и соответственно определяет вариант реализации требования. К примеру, имеется ли такая функция и, если нет, то как можно подстроить систему под бизнес компании: путем параметрической настройки, дополнительного отчета, допрограммирования на уровне логики или изменения интерфейса.
В итоге при сборе требований для выбора системы достаточно остановится на уровне, на котором поставщику хорошо понятна логика и необходимые информационные потребности бизнеса. Дальше предлагать варианты реализации требований должен уже поставщик.
Подытожим сказанное:
^ вместо изучения системы для ее выбора, необходимо перенести фокус анализа на собственные бизнес-процессы и потребности; ^ источником этих требования являются представители бизнеса, а не ИТ-специалисты;
^ ИТ-специалисты собирают эти требования, «переводят» их на
ИТ-язык и обобщают информацию и вопросы к поставщикам в виде высокоструктурированного документа;
^ поставщики самостоятельно сравнивают эти требования со своими возможностями и готовят ответы;
^ ответы обрабатываются ИТ-специалистами и результаты доводятся до бизнеса4.
Стратегическая увязка проекта выбора
Ускорение изменений в бизнесе требует более быстрого развертывания (выбора и внедрения) систем. Всегда существует разрыв между той поддержкой, которую предоставляет отдел ИТ, и тем, что необходимо бизнесу в данный момент. Преодоление этого разрыва обеспечивается ИТ-стратегией, которая определяет целевое состояние ИТ на перспективу и позволяет выстраивать его с необходимым упреждением по отношению к изменению бизнеса.
При внедрении часто возникает дилемма: «натягивать» бизнес-процесс на систему или «натягивать» систему на бизнес-процесс. Ни то, ни другое не является окончательно правильным решением. В первом случае получается законсервированное состояние бизнеса, упускается возможность для улучшения. Опыт показывает, что и второй вариант практически никогда не приводит к успеху. Это связано с тем, что за редким исключением невозможно построить бизнес по образцу системы. В России такие проекты оказались в массе своей провальными, что объясняется неустоявшейся экономикой, в которой стандарты ведения бизнеса меняются слишком быстро и не соответствуют зарубежной практике.
Теперь рекомендуется совершенно иной подход: система выбирается под целевое состояние - будущее состояние бизнес-процессов, определяемое стратегией предприятия. Таким образом, и бизнес-процессы, и ИТ-
обеспечение как бы стремятся к единому целевому состоянию (рис. 3).
В этом есть некоторый парадокс: система должна выбираться так, как если бы она была уже внедрена. То есть должно быть представление о том, как бизнес-процесс будет осуществляться в будущем, и как ИТ-си-стема ложится на него. Для этого на проекте должен быть эксперт, который бы представлял, как система может быть использована. Такой человек, обладая знаниями о типах программных систем и их потенциальных возможностях, смог бы найти им применение. Он должен уметь совместить целевое состояние бизнеса с ИТ.
В итоге получается, что осознание предприятием того, для чего ему нужна автоматизированная система, — это самый важный момент, позволяющий не ошибиться в выборе. Цели должны быть определены с точки зрения стратегии бизнеса, причем они должны быть таковы, чтобы их можно было измерять и оценивать. Этот вопрос не так прост, как может показаться на первый взгляд, и поэтому неудивитель-
но, что ответ на него часто вызывает затруднения.
Требования к системе должны проистекать из целевого состояния, а не из текущего. В этом случае можно разрешить противоречие между быстротой изменения бизнеса и длительностью процессом внедрения системы. Кроме того, необходимо увязать целевые бизнес-потребности с целевой ИТ-инфраструкту-рой (рис. 4).
При обосновании тех преимуществ, которые получает организация от внедрения ИТ в соответствии с принципом «Преимущества взамен на инвестированные средства» (Уа1ие-£ог-Мопеу), необходимо помнить, что дополнительная ценность и преимущества получаются на стыке «Бизнес — Архитектура
ИТ», и прежде всего в области при-
4 Автор готов подробнее ответить на вопросы и дать рекомендации по методике всем заинтересованным читателям.
Синхронизация развития бизнеса и ИТ-инфраструктуры
(Текущее \ у/ состояние /
Целевое
состояние
Бизнес-стратегия
(Текущее \ Уу/ состояние / Д I
Целевое
состояние
1Т~стратегия
Май-июнь 2009 г. 51
Структура «устаревшего» проекта автоматизации ★
X“.)
Структура методологически правильного проекта автоматизации
Анализ (Л£ 15) и концепция (ІО Ье)
Выбор Дизайн Разработка
системы (ТО ВЕ) решения
кладных систем. В то же время это требует затрат, связанных с созданием и развитием архитектуры ИТ, что является результатом реализации ИТ-стратегии.
Правильный подход состоит в концентрации на той стороне этих отношений, которая связана с получением дополнительной стоимости, преимуществ (Added-Va1ue), поскольку бизнес-руководство, когда оно достаточно глубоко понимает преимущества, получаемые от реализации ИТ-проектов, обычно гораздо лучше представляет, какие средства оно готово инвестировать в эти проекты. Такой подход увеличивает шансы на получение реальной поддержки ИТ-проектов со стороны бизнес-руководства. Это то, что называется «иметь спонсора проекта». Как только проект «скатывается» исключительно в область информационных технологий, его успех и поддержка уже не соответствуют реальным целям бизнес-руководства.
Таким образом, взаимосвязь бизнес-стратегии и развития ИТ на предприятии должна характеризоваться следующим образом:
^ В основе должна лежать современная точка зрения на ИТ-архи-тектуру как на производную от бизнес-стратегии и бизнес-задач предприятия.
^ Стратегия развития ИТ должна базироваться на четком понимании бизнес-целей, стратегии и видении целевого состояния.
^ ИТ-инициативы, проводимые в компании должны выполнять заказ бизнеса. ИТ-стратегия определяет инициативы по совершенствованию бизнес-процессов на основе информационных технологий.
^ Заказчик (владелец бизнес-процесса) несет ответственность за эффективность работы в своей бизнес-области. Он должен выступать «генератором идей» по реинжинирингу его бизнес-процессов.
^ ИТ-структуры, со своей стороны, должны предлагать то или иное решение на рассмотрение заказчика, сообщать об имеющихся технологических возможностях, которые помогут достичь бизнес-цели.
Фокус на анализе, предшествующем выбору
Проводя автоматизацию, многие компании делают одну ошиб-
ку: они сначала выбирают систему для автоматизации, а потом уже просят ее поставщика подробно проанализировать нужды предприятия. При этом складывается ложное впечатление, что выбор бесплатен, а деньги нужно платить только за оставшиеся части проекта внедрения. На рис. 5 и 6 показаны структуры «устаревшего» и методологически правильного проекта автоматизации, где звездочками отмечены моменты начала привлечения внешних ресурсов (вне-дренца).
Необходимо сразу же объявить о разделении проекта автоматизации на два подпроекта: по выбору и по внедрению.
Обычно стоимость анализа, проводимого внедренцем, составляет 25—30% от общего бюджета проекта внедрения. Поэтому можно взять консервативные 20% и потратить их на анализ и описание системы. Общая сумма расходов не вырастет и, даже наоборот, может сократиться. Тогда не придется переплачивать за дополнительный анализ со стороны поставщика и доработку неидеально «севшей на бизнес» системы. Сделав подробный анализ, можно также избежать двусмысленности в отношениях с поставщиком, который может неверно истолковать расплывчатые, неформализованные требования заказчика. В первом случае поставщик либо поднимет стоимость за проведение более подробного анализа со своей стороны, либо составит более жесткий договор, ограждающий его от возможных негативных последствий.
Выбор не системы, а конечного решения
Готовые системы никогда не «ложатся» на бизнес без некоторой доработки. При этом надо понимать, что заказчик, «покупая сверла, нуждается в дырках». Покупая КИС, предприятие нуждается не в системе, а в решении своих проблем. Таким образом, выбор КИС — это фактически выбор решения проблем, то есть умения поставщика создать необходимое решение путем доработки базовой функциональности исходного пакета в рамках бюджета. Вот почему коммерческие предложения следует оценивать комплексно, как совокупность «система+интегратор», а не поэтапно.
Обманчивость «лучших практик»
Нельзя не остановиться на одном моменте взаимоотношений с поставщиком на проекте выбора системы. Весьма привлекательной для заказчика может стать идея «лучшей практики» или «лучшего готового решения» для его бизнеса. Действительно, зачем что-то делать, изучать и сравнивать, если можно просто купить «лучшую практику». Многие руководители наивно предполагают, что их бизнес стандартен, а значит, где-то существует набор бизнес-кейсов, один из которых им обязательно подойдет.
Это заблуждение подкрепляется маркетинговой политикой разработчиков ПО, которые утверждают, что обладают неким набором готовых решений для самых разных сфер бизнеса. На самом деле, под этим всего лишь подразумевается, что поставщик обладает опытом работы над проектом во внешне похожей компании, заказчик которого выдвигал нестандартные требования и тщательно следил за их выполнением. И, возможно, эти разработки вошли в стандартный пакет.
Однако нет никаких гарантий, что бизнес одного заказчика, пусть даже он работает в той же сфере, похож на бизнес другого. Например, одна мебельная компания работает по модульной системе сборки кухонь. У нее на складе всегда имеются определенные модули, из которых можно собрать заказ. Мебель отгружается, как только сделана планировка кухни из предложенных блоков. Другая компания начинает производство компонентов только после того, как был сделан дизайн кухни, не ограничивая при этом заказчика выбором строго определенных модулей. Если компания, работающая по второй схеме, купит ПО, сделанное для первого производителя, то она должна будет полностью перестроить свой бизнес, чтобы ПО эффективно заработало.
И еще. «Мы купим программу, и она решит все наши проблемы,» — так многие думали после перестройки, покупали программы под аналогичные обещания продавцов систем и на собственных ошибках учились, что системы надо внедрять и, более того, настраивать, хотя и это еще не гарантирует решения проблем. Это сейчас понимают почти все.
Поэтому не ищите легких путей - ищите правильные! л
Рис. 6
Рис. 5
