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

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

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

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

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

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

Лицом к заказчику

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

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

Существует точка зрения, согласно которой бизнесу, мол, вообще незачем вникать в проблемы ИТ, достаточно лишь взять на работу высококвалифицированных экспертов. На первый взгляд, это представляется решением проблемы, но потом выясняется, что это не обеспечивает долгосрочный выход из положения. Дело даже не в высокой стоимости их услуг — эксперт зачастую просто не желает постоянно заниматься одной и той же рутинной работой, да и компания не всегда хочет зависеть в своей работе от отдельных сотрудников. А что произойдет, если они уволятся? С течением времени хорошие специалисты стараются заняться более интеллектуальным трудом, нежели ответы на вопросы пользователей и постоянный мониторинг ИТ-систем. Что же в этой ситуации будет гарантировать постоянную, качественную поддержку и сопровождение ИТ-инфраструктуры компании?

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

Интересно, что известный всем финансовый фактор (нехватка денег) не является первопричиной проблем. Имея даже самые комфортные финансовые условия, все равно необходимо разобраться и понять, каких специалистов надо пригласить, что они должны делать, как станут взаимодействовать друг с другом, каким образом они будут документировать накапливаемые знания. Другими словами, сначала следует определить порядок организации работы, а уже потом можно будет объективно сказать, сколько такой «механизм» стоит. Интересно, что после подобного детального анализа порядка организации работы руководителям становится намного проще принимать решение о выделении финансовых средств ИТ-департаменту. В этом случае становится досконально известно, на что расходуются средства.

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

  • инициировать новый крупный проект для того, чтобы кардинальным образом модифицировать саму ИТ-инфраструктуру;
  • эксплуатировать имеющуюся инфраструктуру, наращивая нагрузку и укрепляя ее в авральном режиме (нередко это приводит к тому, что на предприятии появляются десятки серверов, на которых работают, например, модули «1C», поддерживаемые двумя-тремя специалистами уникальной квалификации).

Решает ли это задачу качественной работы ИТ? Дает ли это информацию руководству для принятия аргументированных финансовых решений относительно ИТ? Неизбежно наступает «момент истины», побуждающий бизнес-руководителей и ИТ-менеджеров по-иному взглянуть на ситуацию. Нельзя работать над улучшением качества ИТ-обслуживания, принимая во внимание лишь технические аспекты ИТ-инфраструктуры и исключив из рассмотрения принципы организации работ (процессы) и слаженность работы персонала. Как сказал Альберт Эйнштейн: «Вы никогда не сумеете решить возникшую проблему, если сохраните то же мышление и тот же подход, который привел вас к этой проблеме».

Границы проектного управления

Бесспорно, необходимо модернизировать инфраструктуру, и управление проектами играет здесь важную роль, помогая запустить в эксплуатацию требуемую функциональность либо произвести изменения в заданное время и располагая определенными ресурсами. Стандарты управления проектами (в частности, PMI PMBoK) интенсивно развиваются и становятся все более актуальными. Многие компании видят огромную пользу в структуризации проектного управления и создании проектных офисов, позволяющих координировать все проекты. Действительно, без четкого управления проектами эффективность ИТ немыслима. Но только ли через своевременное исполнение проектов пролегает путь к эффективному использованию ИТ? Все ли решают архитектура системы, вычислительные, телекоммуникационные мощности, совершенство программного обеспечения, точность и своевременность их ввода в работу?

Если даже предположить, что обоснование проекта было хорошо выполнено (что само по себе нетривиальная творческая задача), и ожидаемые результаты имеют бизнес-отдачу, то все равно многое «интересное» начинается уже после завершения проекта, когда настает время ответить на следующие вопросы.

  • Не изменилась ли бизнес-ситуация за время реализации проекта? Как велось управление запросами на изменения создаваемой системы? Не превратилась ли новая система в «монолит», автоматизирующий задачи «вчерашнего дня» и ставший камнем преткновения для дальнейшего развития?
  • Создана ли инфраструктура для сопровождения, позволяющая делать требуемые модификации и настройки, грамотно документируя результаты и передавая их в промышленную эксплуатацию?
  • Правильно ли укомплектован персонал, обеспечивающий работу ИТ-инфраструктуры? Достаточно ли сотрудников, каким образом распределены задачи между ними? Имеются ли регламенты и правила работы, или их деятельность основывается лишь на личном собственном опыте (что делает работу ИТ-комплекса в целом достаточно непредсказуемой)?
  • Получают ли пользователи комплексное ИТ-обслуживание требуемого качества, или им предложено стать специалистами по работе со сданной в эксплуатацию системой (точно так же в недавнем прошлом каждый водитель должен был быть специалистом по ремонту своего средства передвижения)?
  • Сколько стоит ИТ-обслуживание в целом? Достаточно ли у компании ресурсов на развитие и расширение персонала, обучение, НИОКР, современные средства управления ИТ-инфраструктурой? Реальная стоимость сопровождения зачастую далеко не исчерпывается прямыми затратами на вновь создаваемую или существующую систему, особенно если она не одна. Те ли это затраты, которые ожидает и на которые готов идти бизнес?

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

Управление ИТ-услугами

А что если вместо того, чтобы по отдельности решать каждую задачу, возникающую при организации взаимодействия бизнеса и ИТ-подразделения, попытаться обобщить проблемы и способы их решения? Задавшись 15 лет назад таким вопросом, компьютерное сообщество совместно с бизнесом предложили библиотеку IT Infrastructure Library (ITIL), ставшую сегодня для ИТ-индустрии чем-то вроде таблицы Менделеева, включающей весь передовой опыт управления ИТ. Для систематизации этого опыта был предложен структурированный подход, который лег в основу популярной сегодня области менеджмента — управления ИТ-услугами (IT Service Management, ITSM). Интересно, что, несмотря на то, что упоминание об ITIL/ITSM встречается в России уже на протяжении последних шести-семи лет, только сейчас широкий круг заказчиков начинает проявлять неподдельный интерес к изложенным вопросам (кстати, выходящим за рамки службы поддержки пользователей, с которой ранее отождествляли ITIL) и использовать этот опыт на практике.

Примечательно, что в отличие от других стандартов, таких как ISO 9000 или CobiT, использование ITIL не является обязательным (исключение — Великобритания, где он не так давно был узаконен как государственный стандарт), тем не менее уже тысячи компаний в мире применяют подходы ITIL/ITSM. Что же заставляет их делать это? Прежде всего, структурированность и фундаментальность подхода. Благодаря этим методам компании, они могут не только «залатать дыры», но и сформировать подходы к менеджменту в каждой компании, позволяющие не искать «концы» каждый раз, когда возникает проблема. Руководство компании обретает уверенность в том, что ИТ-подразделения правильно решают свои задачи, что приняв решение сегодня, им не придется снова возвращаться к этому вопросу.

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

Кому нужен ITIL?

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

В этой связи многие руководители предприятий и ИТ-подразделений стараются найти детальные ответы на следующие вопросы.

  • Зачем нужен ИТ-департамент, какие задачи он решает? Какую бизнес-пользу он приносит? Дань ли это «моде на высокие технологии» или ИТ имеет вполне определенную ценность для бизнеса предприятия? Есть ли весомые оценки нематериальных преимуществ от развертывания ИТ-решений? Как получить реальные преимущества от применения ИТ?
  • Какие виды услуг предоставляет ИТ-подразделение? Насколько качественно налажено это обслуживание и соизмерима ли цена? Нужны ли новые ИТ-проекты, или требуемая функциональность может быть реализована за счет развития уже развернутых решений?
  • Как управлять всем портфелем проектов компании, в которых задействованы ИТ? Как состыковать и согласовать многие отдельные ИТ-проекты с другими ИТ- и бизнес-проектами?
  • Что делать, когда ИТ-проект попадает под волну изменений в бизнесе или технологическом окружении? Следует ли считать приостановку проекта его провалом, или же это логичная смена приоритетов в ответ на динамику бизнеса и ИТ?
  • Как должно быть организовано выполнение ИТ-проекта, чтобы требуемый результат был получен в срок в рамках согласованных бюджетов и ресурсов?
  • Что будет после окончания проекта? Кто и как будет сопровождать внедренные ИТ-решения, чтобы они не только надежно работали, но и продолжали соответствовать динамике бизнеса и способствовали его развитию, а не тормозили его?

Ответ на каждый из поставленных вопросов требует серьезного обсуждения. Сегодня, когда ИТ оказываются в центре всех существенных изменений в бизнесе (яркий пример — процессы слияния и поглощения компаний), руководители предприятий все более вовлекаются в процесс принятия ИТ-решений: в мире сейчас 60% решений о финансировании ИТ принимается руководителями предприятий или функциональных подразделений, и лишь 40% — ИТ-руководителями.

С чего начать? Может, с SLA?

Поиски «философского камня» эффективности ведутся давно, породив, в частности, соглашения об уровне предоставляемых услуг (Service Level Agreements, SLA) и выпустив из бутылки «джина» аутсорсинга, к помощи которого сейчас обращаются игроки ИТ-рынка. Вот один из последних примеров: в одном недавно опубликованном компанией Veritas Software исследовании Dynamic Markets было показано, что сегодня неуклонно растет число организаций, применяющих практику заключения SLA между ИТ-департаментами и бизнес-подразделениями. Согласно этому исследованию, из 1000 опрошенных организаций и центров данных 59% уже ввели у себя практику заключения SLA, что позволило сделать более прозрачными отношения между ИТ- и бизнес-подразделениями. В организациях, принявших SLA, скорость выполнения операций выросла на 37%, надежность системы на 35% и на 29% сократилось время восстановления после перерывов в работе. Кроме этого, на данных предприятиях произошла расстановка приоритетов и распределение ресурсов в нужном направлении, а руководители бизнес-подразделений теперь используют SLA для улучшения работы своих отделов, пытаясь вместе с ИТ-департаментами найти баланс между уровнем обслуживания и его стоимости. Однако 39% организаций пока и не думают об SLA, используя типовые инструменты бюджетирования и планирования работы ИТ, оценивая эффективность ИТ по степени исполнения ИТ-бюджета и его объему относительно некоторого периода в прошлом.

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

Оборудование, прикладное и системное ПО развиваются по своей траектории, поэтому неудивительно, что в общем случае трудно предложить унифицированную метрику оценки эффективности взаимодействия бизнеса и ИТ-подразделений, хотя структурированный подход существует — это управление ИТ-услугами. В этих условиях соглашения об уровне предоставляемых услуг способствуют улучшению взаимоотношений между подразделениями, а сами услуги описываются точнее, на языке бизнес-заказчиков, с требуемой степенью детализации. Соответствие реально предоставляемого обслуживания оговоренному с бизнесом уровню позволяет дать ответ о качестве обслуживания. Прозрачнее становится процесс оценки качества и стоимости услуг, яснее схема взаимодействия с ИТ. Многие крупные компании стремятся сегодня отдать на аутсорсинг непрофильные виды деятельности и, как следствие, руководство заставляет сотрудников формулировать требования SLA к таким компаниям. Даже если вопросы ИТ не переданы сторонней организации, бизнес-руководство все равно заинтересовано в SLA, поскольку данное соглашение позволяет осуществить «инвентаризацию» видов ИТ-обслуживания в компании и определить их реальную стоимость.

При этом важно понимать, что цена вовсе не обязательно должна быть частью SLA. Так бывает в компаниях, которые еще не внедрили у себя детальные механизмы финансового учета, позволяющие определять себестоимость ИТ-обслуживания, или если организация по определенным причинам не хочет рассматривать ИТ как отдельный самофинансируемый центр внутри своей компании. Цель SLA в этом случае — управление ожиданиями бизнеса: заблаговременное выяснение потребностей и организация предоставления такого обслуживания, которое воспринимается бизнесом как качественное (то есть соответствующее его ожиданиям). Кроме того, такая прозрачность бизнес-потребностей значительно облегчает переговоры об ИТ-бюджетах. Если бизнесу требуется некоторое обслуживание, то детальная сервисно-ресурсная модель позволяет доказать, что другого более дешевого способа предоставления обслуживания нет. Можно сказать и так: SLA помогает выстроить модель «райтсорсинга» (сбалансированного выбора внешних и внутренних поставщиков услуг) путем комбинации взаимоотношений с внешними компаниями (аутсорсинг) и внутренними подразделениями (инсорсинг).

Наиболее значимым в работе с сервисными соглашениями является осознание того, что SLA не могут и не должны заменять взаимодействие между руководителями. Это инструмент в руках менеджеров, а не самоцель компании или ИТ-отдела. Несмотря на ясность этого принципа, имеется множество примеров, когда компании в угоду краткосрочным политическим интересам торопятся с объявлением перехода на обслуживание по соглашениям SLA без какой-либо детальной их проработки. Это приводит только к нарушению взаимопонимания ИТ-специалистов и бизнеса, который видит в таких соглашениях исходящую со стороны ИТ-подразделения попытку обособиться. Кому же такое понравится?

Можно взять обратный пример, когда компании не ведут структуризацию внутренних ресурсов, нацеливаясь на сопровождение и развитие и, как результат, не имеют полной картины стоимости предоставления ИТ-обслуживания требуемого качества. Как в таком случае понять, какие ресурсы требуются для обеспечения качественной работы ИТ и то ли это «качество», за которое бизнес готов платить деньги? Отсутствие такой прозрачности возможно лишь для компаний со стабильным бизнесом, относительно неизменным ИТ и сложившимся за годы работы ИТ-бюджетом. Таких с каждым днем остается все меньше.

Соглашения SLA должны составляться после изучения потребностей бизнеса и детальной оценки реалистичности выполнения и своей стоимости. Предусмотренные в них ключевые показатели (Key Perfomance Indicators, KPI) обязательно должны отслеживаться, поскольку их значения и динамика их изменения являются одними из важнейших внешних показателей качества работы ИТ. В этом случае они служат как долгосрочным политическим интересам достижения эффективности и управляемости, так и текущим задачам обеспечения качественной работы ИТ-подразделения. Кстати, это также может быть и важной политической задачей внутри компании.

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

Нужны новые решения

Сами по себе компьютеры были эффективны при автоматизации рутинных операций. При реинжиниринге сложных бизнес-процессов, которые становятся все более динамичными, ситуация меняется: появляется потребность в приложениях с коротким сроком жизни — всего в один-два года. Сегодня ИТ-мир живет гораздо быстрее, чем многие другие области деятельности. Десятки и сотни лет, отведенные развитием экономики, например, для банковского сектора и промышленности, для мира современных высоких технологий сжаты в десятилетия. В результате развитие принципов ИТ-менеджмента происходит взрывным образом, включая в себя все лучшее, что накоплено в мире.

В наши дни библиотека ITIL стала стандартом де-факто для организации процессов предоставления ИТ-обслуживания. В ближайшем будущем ожидается, что мир ITSM сделает новый шаг вперед, превратившись из средства описания «что должно быть сделано» в методику, помогающую организациям ответить на вопрос «как это должно быть сделано». Библиотека ITIL позволяет создать систему координат и понятий для коммуникаций как внутри самой компании, так и извне при взаимодействии с поставщиками и потребителями.

Работа в соответствии с правилами управления ИТ-услугами становится эффективной, когда все субъекты бизнеса осознают, что нет больше такого понятия, как отдельная ИТ-система, а гибкость и адаптивность, результативность и экономическая рациональность стали ключевыми требованиями времени, для которого прямой «командно-административный» подход «вертикальных отделов» уже не годится. Прошло время, когда каждый был сфокусирован только на своем задании, и никто не отвечал за эффективность всех процессов, обеспечивающих работу компании. Нужны новые измеряемые и управляемые решения, нацеленные на конечный результат.

Михаил Потоцкий — управляющий партнер компании IT Expert, m.pototsky@itexpert.ru


ITIL — новый взгляд на уже известные законы?

И да, и нет. ITIL не открывает невиданных истин, и отдельные виды деятельности, рекомендованные ITIL, нередко уже имеются в организациях. Это создает ощущение того, что все предлагаемое ITIL уже известно и работает. Однако полезно задуматься, всегда ли эти действия скоординированы, целенаправленны, всегда ли в них четко распределены роли и ясны принципы взаимодействия между сотрудниками, выполняющими эти роли, всегда ли гарантирован качественный повторяющийся результат, подтверждаемый количественными показателями эффективности? Есть ли в организации «контуры управления» этими видами деятельности, направленными на мониторинг и оптимизацию работы? Здесь начинается ответ на вопрос: а есть ли в компании управляемые процессы, рекомендованные ITIL?


Пример: машиностроительный завод

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

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

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

С появлением новых подразделений и партнеров потребовалось внести изменения в функциональность комплекса. Кто мог бы взять на себя решение всех этих задач? Следует ли предприятию нанять разработчиков в штат? На базе каких технических средств следует выполнять эту разработку и тестирование? Бюджет проекта уже был закрыт, а в операционном бюджете были предусмотрены лишь средства на сотрудников службы Help Desk.

Более того, базовые системы компании — транзакционная и финансовая — сильно устарели (поскольку находились в эксплуатации более пяти лет), операционные системы и компьютерное оборудование также были далеко не новыми. В результате содержание ИТ-инфрастуктуры превратилось в трудоемкую проблему, решение которой требовало немалых денег.

Кроме того, стало очевидно, что по мере продвижения идей ИТ-среда становится все более инертной и мешает дальнейшим преобразованиям. Основная цель принятой ранее ИТ-стратегии — повышение эффективности производства — была выполнена, но возник новый спектр задач, об актуальности которых ранее не задумывались. В частности, для долгосрочного планирования производства предприятию требовалось внимательно анализировать клиентскую базу, следовательно, нужны были средства управления отношениями с клиентами (CRM), а интеграция цепочек поставок (SCM) позволяла ускорить оборот капитала. Однако к такому развитию событий не был готов ни созданный комплекс, ни ИТ-персонал. Впрочем, это неудивительно, поскольку таких задач изначально не ставилось.

Предприятию пришлось начать фундаментальную перестройку ИТ-инфраструктуры, однако недавно созданная «Система реализации полуфабрикатов» была ориентирована только на имевшиеся системное ПО и платформы. Потребовалась полная переделка всей системы, и это при том, что она находилась в использовании немногим больше 18 месяцев!

Возникла еще одна проблема. Для повышения точности и уменьшения числа ошибок персонала каждый бизнес-шаг был «встроен» в систему — она требовала выполнения четкой последовательности операций на протяжении всего процесса, причем в точном соответствии с установленным порядком. Другими словами, вся логика бизнес-процесса была «зашита» в систему. Несмотря на то, что начальная цель — быстрота и точность — была достигнута, гибкость бизнес-процессов, которой генеральный директор начал придавать исключительную важность, была утрачена. В течение первых полутора лет после внедрения системы это не имело серьезного влияния, однако в ходе реорганизации бизнес-процессов стало ясно, что система становится главным препятствием. «Существующая система не позволит нам сделать это», — таким был ответ ИТ-специалистов на большинство вопросов генерального директора. Заложенные в начале проекта показатели возврата на инвестиции были достигнуты, однако в итоге пришлось фактически списать систему после полутора лет ее эксплуатации и приступить к разработке нового комплекса.