В журнале Intelligent Enterprise (№5/2012) опубликована статья заместителя генерального директора по стратегическим проектам Михаила Заборова и директора по маркетингу и продажам Максима Михалева, посвященная клиентоориентированной автоматизации. Как сделать процесс оказания сложной услуги по созданию (или серьезной кастомизации) масштабного ИТ-решения класса ERP максимально прозрачным и «приятным» для клиента и добиться при этом качественного результата? Как найти профессионального и ответственного подрядчика, который будет ориентироваться на интересы заказчика и доведет проект до результативного внедрения? Эти вопросы чрезвычайно остро стоят перед поставщиками и заказчиками крупных ИТ-решений, и наши специалисты предлагают свое видение проблемы и путей ее решения.
Если угождаешь, угождай каждому по-своему.
(Филип Дормер Стенхоп Честерфилд)
Каждый CIO крупной компании не понаслышке знает, что такое внедрение масштабного ИТ-решения класса ERP — будь то разработка крупного вендора или система, сделанная на заказ. Дело это, мягко говоря, малоприятное — нервное, долгое, трудозатратное, с высокой степенью неопределенности.
С чем это связано? Почему CIO зачастую делают все возможное, чтобы «отложить в долгий ящик» замену или внедрение крупных ИТ-компонентов? Почему сам процесс кастомизации и внедрения отнимает у бизнес- и ИТ-специалистов со стороны заказчика столько сил и времени, не гарантируя при этом качественный результат? И с чем связано то, что порой даже в случае успешного внедрения действительно нужного ИТ-решения заказчик все-таки остается недоволен?
Сложный рецепт
Все дело в том, что автоматизация с глубокой кастомизацией — и серьезная адаптация вендорского решения, и создание ИТ-системы на заказ — сложная услуга, требующая особого подхода. Прежде всего, огромное значение приобретает правильная организация процесса разработки (адаптации) и внедрения, ведь в случае сложных услуг процесс не менее важен, чем результат.
Кроме того, услуга по созданию масштабных ИТ-систем класса ERP обладает рядом особенностей, увеличивающих ее сложность.
- Объект автоматизации — бизнес и его процессы — постоянно меняется. Здесь уместно сравнение с хирургом, который оперирует живой организм, только проекты создания ИТ-систем могут вестись годами на динамично развивающемся бизнесе.
- Как правило, в масштабных проектах автоматизации принимает участие большое количество заинтересованных сторон, каждая из которых преследует собственные цели и имеет отличные от других интересы.
- Процесс оказания услуги по созданию (кастомизации) масштабной ИТ-системы может быть весьма длительным. При этом заказчик получает результат не единовременно, а порциями на протяжении всего проекта. Этому способствует применение современных гибких методологий разработки и итеративного подхода, при которых результат (новая функциональность) «отгружается» заказчику периодически небольшими частями.
- В начале процесса оказания услуги практически невозможно детально описать, каким должен быть результат. Это означает, что на старте проекта ни одна из сторон в точности не знает, каким будет (или должно быть) разработанное ИТ-решение. Масштабная система класса ERP — очень сложный объект, а ее разработка (глубокая кастомизация) ведется в условиях непрерывно меняющегося бизнеса.
- Качество результата — разработанного (или глубоко кастомизированного) ИТ-решения — оценить очень сложно. Дело в том, что ИТ-система — объект нематериальный, его практически невозможно «рассмотреть со всех сторон», исчерпывающе описать и достоверно оценить. Выводы о том, насколько хорошо и надежно предложенная ИТ-система поддерживает бизнес-процессы заказчика, можно будет сделать лишь после нескольких месяцев (а то и лет) промышленной эксплуатации.
Необходимые ингредиенты
Таким образом, у заказчиков крупных ИТ-решений есть объективные основания опасаться сложностей и неопределенностей, связанных с подобными услугами. Однако современные компании-подрядчики, оказывающие профессиональные услуги по разработке (кастомизации) и внедрению масштабных ИТ-систем, делают все, чтобы процесс создания ИТ-решений был максимально комфортным, прозрачным и предсказуемым для клиентов. Иными словами, они действуют клиентоориентированно.
Но что конкретно подразумевает клиентоориентированность применительно к сложной услуге создания (или глубокой кастомизации) крупных ИТ-систем? Мы выделим несколько главных характеристик.
- Прозрачность. Процесс создания ИТ-решения должен быть выстроен таким образом, чтобы клиент всегда был в курсе ведущихся работ и мог получить сколь угодно подробные разъяснения по любым возникающим вопросам.
- Заказчик может рассчитывать, что специалисты подрядчика будут общаться с ним в понятных ему терминах и демонстрировать действие ИТ-систем на данных, приближенных к реальным. Должны быть обеспечены все условия для участия клиента в принятии ключевых решений — необходимо предоставить ему инструменты и артефакты, которые позволят быстро улавливать суть, не вдаваясь в ненужные подробности; кроме того, заказчик должен получать оперативные разъяснения обо всем, что для него делается.
- Современные гибкие методологии разработки подразумевают регулярные (от недели до двух-трех месяцев) демонстрации хода работ по автоматизации и периодические поставки ПО. Эти демонстрации, а также вся необходимая документация, протоколы встреч и новые версии ПО позволяют заказчику всегда быть в курсе процесса и результатов разработки, а также по необходимости корректировать ход работ и приоритетность задач.
- Кроме того, у заказчика должна быть возможность разобраться в том, как устроена команда, работающая на его проект, и познакомиться с исполнителями. Можно даже организовать временное участие специалистов заказчика в работе проектной команды (на территории подрядчика) — CIO наверняка по достоинству оценит такую открытость.
- Клиент может при желании углубиться в детали проделанной для него работы: ему подробно расскажут, что именно было сделано, в чем была причина проблемы и почему было принято именно такое решение, каковы были альтернативы и т. д.
- Предсказуемость. Заказчик должен быть уверен, что подрядчик заранее предупредит его обо всех рисках проекта, а также обо всех проблемах или иных обстоятельствах, существенно влияющих на процесс разработки, как только о них станет известно, и предложит варианты их устранения. Кроме того, клиент вправе ожидать, что подрядчик не совершит никаких несогласованных действий, способных повлиять на его бизнес-процессы.
- Гибкость. Клиентоориентированный подрядчик выстраивает все свои процессы — от сбора требований до внедрения — исходя из потребностей клиента. Кроме того, процесс разработки должен быть настолько гибким, чтобы заказчик мог в любой момент времени внести в требования к ПО какие угодно изменения, не встречая сопротивления со стороны подрядчика. (Конечно, при этом необходимо понимать, что могут двигаться планы и сроки, а часть проделанной и оплаченной работы, возможно, окажется ненужной.)
- Однако гибкость не ограничивается процессами компании-подрядчика — само создаваемое ИТ-решение должно безболезненно встраиваться в имеющийся ИТ-ландшафт и быть способным к развитию, чтобы поддерживать меняющийся бизнес заказчика на протяжении всего срока эксплуатации.
- Профессионализм. Заказчик должен быть уверен, что его проектом будут заниматься опытные профессионалы, а разработанная ИТ-система будет соответствовать всем стандартам качества ПО. При этом опыт и признание специалистов подрядчика должны быть доказуемыми, то есть существовать в виде портфолио выполненных проектов, отзывов клиентов, сертификатов и лицензий, публикаций и докладов на конференциях.
- Профессиональный поставщик ИТ-услуг охотно делится с заказчиком своим опытом, знаниями и экспертизой, не жалея усилий и времени на разъяснения. Такой подрядчик всегда может предложить хотя бы один вариант решения проблемы заказчика, связанной с проектом автоматизации. Если исполнитель по объективным причинам не может выполнить требования заказчика, он должен предложить альтернативные решения проблемы. Как правило, подрядчик всегда может предоставить клиенту несколько вариантов решения на выбор (быстрый/дешевый/надежный/гибкий).
- Ориентация на интересы клиента. Клиентоориентированный исполнитель искренне заинтересован в решении проблем заказчика и в конечном результате проекта.
- Профессиональные исполнители максимально оперативно реагируют на критичные проблемы заказчика, не «прячась» за формальными регламентами (например, исполнители не уйдут домой, пока склад заказчика не начнет отгружать товар).
- Работа на интересы клиента также подразумевает возможность прекратить отношения, причем компания-подрядчик должна сделать все, чтобы процесс расставания был максимально безболезненным для клиента. Даже если заказчик примет решение заменить систему подрядчика на другую, то клиентоориентированный заказчик выполнит все необходимые для этого работы — миграцию данных, техническую поддержку системы и передачу знаний специалистам заказчика в переходный период.
- Проактивность. Заказчик может ожидать, что инициатива будет исходить от исполнителя, он будет основной движущей силой проекта. Подрядчик должен «думать наперед» и не только предупреждать клиента обо всех нежелательных вариантах развития событий и предлагать меры по их заблаговременному устранению, но и предлагать заказчику наиболее выгодные сценарии развития ИТ-системы.
Счастье есть
Мы надеемся, что перечисленные признаки помогут CIO при выборе клиентоориентированного подрядчика или, по крайней мере, подскажут, что клиент может ожидать от профессионального поставщика ИТ-услуг.
Конечно, здесь описан идеальный вариант взаимоотношений между заказчиком и подрядчиком, поэтому если исполнитель демонстрирует большую часть из перечисленных компетенций — скорее всего, с ним можно и не страшно начинать работу. А если вы в точности узнаете в описании своего подрядчика — вам повезло! Вы нашли по-настоящему клиентоориентированную компанию, которая сделает все, чтобы вам было комфортно и спокойно, а результат не просто оправдал, а превзошел все ваши ожидания.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
