Отношения между ИТ и бизнесом, а также между пользователями и ИТ на практике формируются по цепочке жизненного цикла «выбор — внедрение — поддержка», характерного для любого ИТ-решения. Причем формируются интегрально, без отрыва последующего этапа от предыдущего. Строительство же этих отношений в ИТ-прессе гораздо чаще рассматривают с точки зрения ИТ-служб, одновременно представляя их как чисто двусторонние. Но на процесс их формирования влияют и многие другие участники проектного рынка, которым мы решили предоставить слово в рамках данной статьи.
Выбор решения — стадия знакомства
Постановка задачи как первый этап выбора, по сути, инициирует процесс диалога между бизнесом и ИТ. На этом этапе закладываются качественные характеристики будущего решения. Тот факт, что задачу перед ИТ ставит бизнес, вряд ли целесообразно обсуждать. Более практичен вопрос, до какой степени детализации необходимо доводить постановку. Формулировать ли ее в общих терминах, в конкретных количественных показателях развития бизнеса на перспективу или же в виде определенных требований к ИТ-сервису? «Первичную постановку задач я считаю оптимальным представлять в общих терминах развития бизнеса. Затем совместно с IT-департаментом, равно как и с другими сервисными службами, мы обсуждаем перспективы на так называемых "стратегических сессиях". Они представляют собой нечто среднее между мозговым штурмом и проблемно-целевым семинаром. Так вырабатывается согласованное видение перспектив бизнеса», — утверждает Вадим Карлинский, бывший финансовый директор Пермской ГРЭС. Несколько по-иному формулирует постановку задачи начальник отдела экономического планирования и развития ОАО «Компрессорный комплекс» Денис Петров: «Необходимо привлекать ИТ-специалистов, не описывая перспективы деятельности компании и не выставляя требований к методам обработки информации». По его мнению, целесообразно предложить ИТ-департаменту участие в обсуждении планов, обратившись к нему примерно со следующим открытым вопросом: «Мы хотим принимать определенные бизнес-решения, и нам нужна такая-то информация, которая на сегодня собирается в таком-то виде. Давайте разработаем алгоритм получения необходимой информации на рабочих местах».
Как мы видим, вопрос, необходимо ли раскрывать перед руководителем ИТ-подразделения перспективы бизнеса, сами бизнес-руководители могут трактовать несколько по-разному. Соответственно несколько разные акценты на различных предприятиях могут придаваться согласованному видению бизнес-проблематики со стороны бизнеса и ИТ в долгосрочной перспективе. И все же при подходе к постановке реальной задачи структура отношений становится более универсальной. Перед ИТ-отделом готовы полностью раскрыть текущие приоритеты по принятию бизнесом управленческих решений, предъявить общие требования по наличию информации и ее движению. Со стороны ИТ-департамента, в свою очередь, бизнес ожидает услышать конкретные предложения в отношении алгоритмов реализации и инфраструктурного обеспечения, необходимых для реализации поставленных задач. «Когда выработано согласованное видение перспектив бизнеса, происходит обсуждение и защита предложений CIO на Наблюдательном совете — специальном коллегиальном органе принятия стратегических решений. Эти предложения формулируются уже в формате конкретных требований по реализации алгоритмов, закупке программных средств и конкретного оборудования в соответствии с техническими требованиями», — говорит Вадим Карлинский. Денис Петров подчеркивает и тот факт, что ИТ-отдел наряду с некоторыми другими службами (например, кадровой), является ресурсообеспечивающей. Мнение каждой из этих служб обязательно должно приниматься во внимание при принятии окончательного решения. Суммарное ресурсное обеспечение, а иными словами, цена конечного результата, может оказаться слишком высоким. Значит, будет снижено качество, поскольку последнее не должно рассматриваться вне контекста стоимости его достижения.
В итоге именно на этапе постановки реальных задач и коллегиального их обсуждения ИТ-отдел начинает играть активную роль, и с этого момента закладывается фундамент в отношении качества предоставляемых впоследствии ИТ-услуг. Хотя, опять- таки, судя по приведенным высказываниям, формат вовлечения ИТ-подразделения в число активных соучастников реализации бизнес-целей может носить более или же менее формальный характер.
На этом же этапе формируется и известная проблема разделения инициативы ИТ и бизнеса в отношении изменения бизнес-процессов. По всей видимости, она будет обсуждаться еще долго. «ИТ-специалисты ни в коем случае не могут вмешиваться в бизнес-процессы без специального приглашения владельцев процессов, так как хвост не может вилять собакой, категорично утверждает Вадим Карлинский. — Технологии — это все-таки сервис для бизнес-процессов, а не наоборот». Вместе с тем, например, в одном из недавних выпусков нашего журнала советник президента «ЕвразХолдинга» Элмурод Расулмухамедов прямо высказывал мысль, что дизайн бизнес-процессов — одна из важных функций CIO. Хотя данный вопрос, по всей видимости, стоит (и будет стоять) больше именно в отношении первичной инициативы, а не самой деятельности по реорганизации. По крайней мере Вадим Карлинский ссылается на положительную практику «перекрестного» обучения ИТ- и бизнес-менеджеров, когда первые проходят подготовку, позволяющую им хорошо ориентироваться в бизнес-процессах, а вторые — учатся самостоятельно оценивать возможности и ограничения технологий автоматизации. Напомним, что и Элмурод Расулмухамедов, также утверждал, что 50% времени обучения ИТ-специалистов тратится на то, чтобы познакомить их с механизмами функционирования бизнеса. Остальная половина уходит соответственно на тренинги по программным продуктам.
Важный параметр, косвенно влияющий на адекватность получаемого в результате ИТ-решения, — горизонт планирования, что, в свою очередь, означает возможность синхронизации бизнес-планирования и развертывания поддерживающих бизнес программно-аппаратных платформ. Руководитель группы развития бизнеса московского представительства Procter&Gamble Андрей Погорелый полагает, что в идеале это пять лет. Детальные же сведения, позволяющие правильно построить график проектов, выработать бюджеты и определить ресурсы, необходимы ИТ-отделу не менее чем на год вперед. Вадим Карлинский, комментируя вопрос о сроках предоставления ИТ-подразделеню достоверной информации о развитии бизнеса, дает следующую оценку: «Горизонт обоснованного стратегического планирования составляет два-три года, в зависимости от динамики развития самого бизнеса и стадии его жизненного цикла. Такое планирование должно быть скользящим, то есть каждый год возобновляться на ту же среднесрочную перспективу». Несколько ближе к проблеме внедрения ИТ подходит в данном вопросе Денис Петров. «Период планирования для ИТ зависит от планов линейных служб. Внедрять какой-то продукт, на который ориентировались вначале, может оказаться нецелесообразным, поскольку впоследствии в рамках иной задачи может быть внедрено совсем другое ПО, которое решит заодно и первую проблему», — говорит он. Последнее замечание представляется довольно важным. Дело в том, что количество информационных продуктов автоматизации бизнеса, внедряемых на каждом предприятии, действительно растет, как и их разнообразие даже в пределах одного класса (при нынешнем уровне технологий разработки интеграции приложений). И в такой ситуации пересечение функционала становится вполне вероятной перспективой. И это не говоря уже о трансформации возможностей самих систем, которая за обозначенные два—пять лет при нынешнем темпе модернизации программных продуктов может оказаться весьма существенной. Решение таких задач — наиболее яркий пример необходимости совместной работы бизнеса и ИТ, рассчитанной на перспективу. И это качественно иная проблема, чем оценка сроков внедрения отдельных систем (ERP, DMS или Call-центра). Здесь не обойтись без знания профессиональных нюансов как в области развития бизнеса, так и в сфере развития корпоративных систем. По сути, данная проблема снова возвращает нас к вопросу совместного согласованного видения развития компании со стороны ИТ и бизнес-подразделений, а также к вопросу координации многих ИТ-проектов (так называемых программ внедрения), перспективы которых на российском рынке обсуждались нами в прошлом году (см. спецвыпуск № 3 2004 «От ИТ-проектов к информационным программам»). Здесь мы уже говорим о качестве информационных услуг компании в целом.
Новый этап, новые участники
Стадия внедрения корпоративных продуктов на предприятии характеризуется тем, что в систему отношений между бизнесом и ИТ волей-неволей вторгаются бизнес-консультанты и специалисты по прикладному ПО. С одной стороны, все они безусловно нацелены на взаимодействие с обоими полюсами рассматриваемых нами отношений — с конечными пользователями и ИТ-отделом, причем часто без явных приоритетов каждой из сторон. Так, в компании «Корус Консалтинг» отмечают, что при ведении проектов по внедрению бизнес-систем количество вовлеченных в проект участников с каждой стороны должно быть примерно равным. С другой стороны, компании, связанные с внедрением различных бизнес-систем, могут несколько по-разному интерпретировать ту структуру отношений между ИТ и бизнесом, которая кажется им оптимальной. Так, по мнению Михаила Македонского, исполнительного директора компании «Аплана», занимающейся заказными разработками, ответственность за внедрение новой системы автоматизации чаще всего лежит на ИТ-департаменте, который берет на себя всю работу по взаимодействию с внешним поставщиком. И хотя, по словам Михаила Македонского, ИТ-служба в идеале и должна обеспечивать прямой контакт с функциональным заказчиком внутри компании, требования к ней самой все равно остаются весьма высокими. И в смысле наличия в ней профессиональных аналитиков, ответственных за постановку задачи автоматизации бизнес-целям, и в отношении соответствия создаваемой системы общим корпоративным стандартам (например, политике безопасности), и в отношении создания инфраструктуры сопровождения. Напомним, что в данном случае речь идет о мнении разработчика корпоративных систем, в то время как компании, внедряющие ERP-системы, как известно, придерживаются несколько иных позиций, предпочитая вести консультации, в частности и по вышеперечисленным вопросам, непосредственно с руководителями подразделений. Компании-поставщики в принципе тоже вправе иметь собственные взгляды (пусть явно и не высказываемые) в отношении, к примеру, оптимальной структуры ИТ-отдела заказчика. Такие мнения, как правило, формируются исходя из собственного опыта взаимодействия с заказчиком, а опыт у каждого свой. Так, специалисты «Апланы» в идеале ожидают от ИТ-службы четкого разделения на группу развития и группу эксплуатации, а в «Корус Консалтинг» говорят о подразделении информационного департамента на бюро стратегического планирования и бюджетирования, аналитическое бюро, занимающееся анализом цен и тенденций, а также службу поддержки.
Конечно, все вопросы построения ИТ-службы и структуры ее разделения ответственности с бизнес-подразделениями, о которых говорилось только что, являются прерогативой самого заказчика. Но стоит учитывать все эти нюансы, переходя от внедрения одного класса систем к внедрению других. И это напрямую касается ведения уже упоминавшихся мультипроектных программ внедрения и обеспечения качества работы ИС в целом по предприятию.
Поддержка — процесс творческий
Перейдем теперь к поддержке работы информационных систем, наиболее прямо отображающей механизмы коммуникации ИТ-отдела с пользователями. В попытке хотя бы в минимальной степени обобщить реальный опыт и стремления самих заказчиков в области поддержки ИТ-систем достаточно четко вырисовывается следующая картина. Методической основой поддержки, к которой так или иначе стремятся практически все предприятия, является традиционный HelpDesk — единая точка контакта ИТ-отдела и пользователей по всем проблемам, возникающим в организации в связи с эксплуатацией ИС. Но, что характерно, она практически никогда не реализуется в «чистом» виде. В недавнем интервью нашему журналу (см. IE № 3 2005) ИТ-директор «Инком-Авто» Борис Славин, опираясь на особенности бизнеса конкретной компании, обосновывал необходимость сочетать поддержку пользователей двух различных методов. Речь идет об «обезличенном», но эффективном при использовании в стандартных ситуациях HelpDesk и об адресной работе с пользователями выделенного сотрудника ИТ-отдела, знакомого с предысторией проблем. Со стороны бизнес-менеджмента звучат похожие мнения. «В отношении информационной поддержки мне представляется оптимальным создание единого «окна» обращения для всех работников, кроме топ-менеджеров, которые обслуживаются индивидуально закрепленными сотрудниками», — высказывает мнение Вадим Карлинский. Денис Петров, комментируя организацию ИТ-поддержки на своем предприятии, тоже говорит о об организации телефонной службы HelpDesk с единым номером, которая обслуживает пользователей по всей номенклатуре проблем, связанных в том числе и с эксплуатацией ERP-системы. «Единственным исключением является поддержка пользователей программы 1С. В отношении нее специально выделен человек, который решает все проблемы, связанные с ее эксплуатацией», — утверждает он. То есть здесь мы имеем разделение методов поддержки не по уровню значимости пользователей, а скорее по функционалу комплексной ИС. Еще одно интересное замечание высказывает Андрей Погорелый: «Очень эффективен подход так называемых «ключевых пользователей», когда на стажировку в ИТ берется на несколько месяцев тот или иной сотрудник. По возвращении в свой отдел он, по сути, становится первым уровнем поддержки и решает 60% проблем». Таким образом, несмотря на явное признание апробированных методик, степень креативности в решении проблем поддержки пользователей на практике оказывается очень высокой
Надо сказать, что технология HelpDеsk зачастую привносится в работу заказчика вовсе не специализированными ИТ-консультантами (внедряющими, к примеру, методы сервисного подхода в работу ИТ-подразделений). В этой связи вспоминается проект по внедрению ERP-системы на Первоуральском новотрубном заводе, где сервис HelpDesk был построен полностью в рамках соответствующего проекта, с помощью встроенных средств разработки. Одновременно возможны случаи, когда функциональность стандартного HelpDesk (а вместе с ней и возможности по поддержки пользователей) существенно расширяется за счет коммерческих систем, ориентированных на решение бизнес-задач, дистанцированных от предоставления ИТ-сервиса. В качестве примера можно привести продукты управления знаниями. «За счет нашего продукта Hummingbird KM можно расширить функции систем управления инцидентами, — говорит Павел Тараканов из компании Hummingbird. — Он позволяет так организовать информацию по ранее разрешенным ситуациям, что пользователь, обращаясь к базе знаний, с одной стороны, учится на чужих ошибках, а с другой — получает возможность, изучив предыдущие обращения, более грамотно сформулировать свою проблему».
Подобные примеры способствуют развитию творческого подхода в организации поддержки пользователей, не отходя в то же время далеко от апробированных методик.
