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

Насколько эксперту помогает его собственный опыт? Казалось бы, ответ очевиден. Опыт — это единственная опора консультанта, и чем его больше, тем более он ценится. “Для широкомасштабного повышения качества проектов мы применяем следующую практику, — говорит Валерий Воробьев, заместитель директора по консалтингу и обучению, управлению проектами и рисками компании «САП СНГ и страны Балтии». — У нас есть высококвалифицированные эксперты-консультанты, которые работают в этой сфере по 5—7 и более лет. И они выезжают на проекты [в помощь к другим консультантам] раз в полтора-два месяца на экспресс-обследование: за три-четыре дня опытный человек все увидит и выдаст соответствующие рекомендации». По сути это практика ротирования наиболее опытных консультантов, опирающаяся именно на их опыт.

Но, с другой стороны, опыт эксперта определяет его границы. Очевидно, что нельзя знать все. «Широта взглядов — опасный союзник при воплощении в реально работающую систему, — говорит Игорь Зимненко, директор по развитию бизнеса компании Sterling Group. — Я не могу дать дельный совет, если я в этом не разбираюсь. С другой стороны, чем больше вы от меня хотите, тем меньше вероятность получить от меня дельный совет». Четкое определение зоны своей компетенции — одно из важнейших качеств консультанта. «Грамотный консультант должен всегда чувствовать границы своей компетенции, — полагает Александр Буйдов, директор по информационным технологиям компании КРОК. — Он, безусловно, должен знать, что если какой-то вопрос выходит за пределы его компетенции, он должен честно сказать — нам нужно привлечь кого-то еще». Вернуться к теме границ компетентности консультанта нас побудили несколько случаев из практики, рассказанных нам консультантами. Случаев, которые в какой-то степени можно считать типичными.

Внедрена, но не работает

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

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

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

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

Перенастройка системы

Другой случай, когда опыт и точное понимание границ своей компетенции имеют не меньшее значение, — это перенастройка уже внедренной ERP-системы под новые параметры и отчеты, необходимые для бизнеса. Здесь в качестве примера хочется привести рассказ другого консультанта об опыте внедрения. В некоей компании потребовалась перенастройка уже внедренной ERP-системы Scala. В проекте сразу же появилась одна странность: почему-то консультанта встревожило заявление владельца предприятия о том, что внедрять он будет только те изменения, которые можно реализовать через систему Scala. По сути, абсолютно логичное заявление. Как я уже писал выше, проведение реинжиниринга бизнес-процессов и перенастройка ERP-системы после внедрения — достаточно традиционный и логичный вариант развития событий. Но консультанта смутила привязанность компании к своей ERP-системе. А в качестве довода — общефилософское утверждение о том, что “в управлении, как и в жизни, нужно делать не то, для чего хорош твой инструментарий, а то, что поможет твоей компании выжить и преуспеть”. Утверждение, безусловно верное, но ничего в этом вопросе не меняющее — компания выбирает ERP-систему именно как платформу для дальнейшего развития и совершенствования управления компанией. Потому и ее настройка, и юстировка бизнеса должны происходить непрерывно и параллельно.

Однако что делать, если выясняется, что консультант недолюбливает установленную ERP-систему? Наверное — задуматься о том, соответствует ли его квалификация поставленным задачам. Если опыт консультанта вызывает недоверие к системе, которая установлена у заказчика, то это явный признак того, что проект в опасности.

Что привело к такой ситуации в нашем примере? Собственные слова консультанта о том, что автор «не является специалистом в настройке ПО вообще и Scala в частности», ставят все на свои места. Довольно дорогую, сложную, многофункциональную систему и должен настраивать неспециалист. У кого есть сомнения в результате такой настройки?

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

Тем не менее эта команда начинает настройку системы и, естественно, сталкивается с массой проблем. Если разобраться в наиболее спорных моментах, то выяснится, что все они связаны со слабой квалификацией членов проектной команды. В частности, одна из сложностей использования системы Scala «…была связана с отслеживанием платежной дисциплины клиента», когда «…нельзя без вмешательства человека начислить скидку или штраф, нельзя узнать, как часто клиент задерживал платеж или, наоборот, платил с опережением… Хотя вся информация в системе содержится». Но, как говорит Светлана Кисельчук, старший консультант компании Scala CIS, «…на основании автоматического (!) расчета средней задержки платежа Scala позволяет как раз рассчитать и сумму штрафа и даже выставлять отдельные счета-фактуры по штрафу. Статистика по платежам показывает товарооборот, способ платежа, действующую ставку штрафа, начисленный штраф, число направленных напоминаний и код кредита по каждому покупателю, а также итоги. Статистика приводится для текущего статистического года, срок действия которого может определять пользователь. Используемый штраф рассчитывается по определенной формуле».

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

Еще одна проблема — оценка средней задержки и платежной дисциплины клиента, которую нельзя «…рассчитать… на несколько разных дат, чтобы посмотреть, как же эта дисциплина менялась». «Средняя задержка платежа рассчитывается непрерывно по мере ввода платежей, — поясняет Светлана Кисельчук. — Расчет базируется на среднем значении разницы между фактическими датами оплаты и сроками платежа по счетам-фактурам. Да, стандартным отчетом одновременно, в одной распечатке нельзя посмотреть сравнение по периодам, но сам расчет может производиться по заданному периоду выставленных счетов-фактур. А с помощью любого другого инструмента формирования отчетности (Crystal, MSXL, MS Access) можно и график построить».

Достаточно, ситуация и так ясна. Неквалифицированная команда проекта его почти провалила. Часть задач совсем не была решена, часть решена крайне «криво». Так, в части управленческой документации у команды не получилось с Crystal Reports, и они перешли на Excel. Еще бы — «штука знакомая и удобная»…

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

Выводы

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

К сожалению, готовых рецептов, как отделить профессионала от, скажем мягко, полупрофессионала, нет. Борис Харас, управляющий консультант IBM Business Consulting Services, так говорит о независимых (в том числе и от собственного опыта) консультантах. “Независимого консультанта не бывает. Это очевидно. Но мы представляем не себя, не независимых консультантов, а консалтинговые компании. И внутри компании может быть достаточно широкая экспертиза». И далее совет заказчику: «Проблема, скорее всего, заключается в адекватности… Консультант — это инструмент, которым должен пользоваться заказчик. И каким бы хорошим ни был инструмент, его либо правильно используют, либо нет. В конце концов основное мерило эффективности привлечения консультанта — что поменялось в бизнесе компании по результатам его работы».

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