О том, как ведутся проекты по внедрению бизнес-приложений, можно говорить и писать бесконечно. Если бы только это помогло вывести их на новый уровень... О своем опыте редактору CRN/RE Ольге Мельник рассказывает руководитель проекта со стороны заказчика (торгово-сервисная территориально распределенная компания), пожелавший сохранить анонимность.
CRN/RE: Какие бизнес-приложения вы используете и какую роль в их поддержке и развитии играют внешние подрядчики?
Заказчик: Наша основная учетная система построена на «1С», уже более восьми лет ее развивает и поддерживает внутренняя команда. Мы прекрасно понимаем, что собственная разработка — это дорого, это непрофильная для нас деятельность. Неоднократно обсуждался вопрос об аутсорсинге разработок, было предпринято несколько попыток, но они оказались неудачными. Казалось бы, подрядчиков по «1С» много. Но даже если выбирать именитых, или с солидным портфолио, или делающих отличный пресейл, результат оказывается неудовлетворительным. Типовая ситуация — сейл замечательный, а разработчики — очень средненькие. Поэтому пойти на такой риск — передавать разработку в чужие руки — мы не готовы.
Другой наш важный инструмент — система автоматизации бюджетирования. На ней мы работаем чуть больше года. Сделана она на основе Oracle Enterprise Performance Management (EPM) System, в частности, применены Hyperion Data Quality Management и Hyperion Financial Management.
Важно, что раньше в бюджетировании у нас, кроме Excel, ничего не было. К переходу на продукты Oracle нас подстегнул не только кризис, но и проведенная в компании реструктуризация, централизация всех основных функций. Была поставлена задача обеспечить «единую правду» для всей компании, но переход на единое хранилище данных не предполагался.
CRN/RE: Как и почему вы выбрали этот инструмент и исполнителей?
З.: Oracle выбрали по сочетанию «цена, качество, капитализация».
Рассматривали еще вариант с «1C», это дешевле на порядок, но все, что нам показали на этой платформе, оказалось сильно кастомизировано! Каждый подрядчик предлагал практически свою разработку. Так как у нас есть собственное решение на «1С», мы прекрасно понимаем, что такое кастомизация, сколько это стоит и с чем это едят. И кроме того, у акционеров есть планы выхода на рынок капитала, и для капитализации компании они считают важным использование иной, чем «1С», платформы.
Выбрав систему, мы провели тендер на выбор подрядчика. Нашелся единственный крупный федеральный интегратор, который смог предложить нам что-то близкое к нашей целевой архитектуре. Изначально в тендере принимали участие шесть компаний, но готовых что-то показать оказалось только три. И показали они нам не то, что было нужно, а то, чем располагали. Я приехал к одному из участников тендера и увидел BI, настроенный на «1С», без следов МСФСО — совершенно не то, что мы просили.
Методически этот проект делали мы сами. Функциональным архитектором был я, как, впрочем, и руководителем проекта. К началу проекта у нас была действующая, уже опробованная модель консолидации, выполненная в Excel. Формальной методологии не было, только идеи.
CRN/RE: Что вы считаете главным для достижения успеха проектов внедрения бизнес-приложений?
З.: Очень важен этап написания ТЗ. Алгоритмы работы не зависят от инструмента. В штате клиента должны быть сотрудники, которые с самого начала вовлечены в проект и понимают, какие алгоритмы, почему и как будут реализованы. Они должны принимать самое прямое и деятельное участие в написание ТЗ, что повышает шансы проекта на успех. Если этого нет, то потом наступает шок. Специалисты компании-клиента получают от подрядчиков нечто совершенно не похожее на знакомую или ожидаемую ими картину. Они привыкли к тому, что в привычном Excel можно проследить, «откуда что берется», проверить каждую цифру. В новом инструменте у них такой возможности обычно нет, и по каким алгоритмам что считается, они совершенно не понимают. Результат — антагонизм. Чтобы преодолеть его, требуются время и большие усилия. Надо сделать так, чтобы с самого начала эти люди понимали, что как считается и откуда берется.
Я видел ТЗ, написанные грандами мирового консалтинга. Сотни страниц. Море текста. Все очень красиво, но никто этого не читает. Нужна табличка в Excel и пояснение, какие формулы будут применены, почему именно эти, откуда возьмутся данные для них.
Проблема и в том, что когда начинается проект, руководство очень часто не осознает, зачем он вообще нужен. Акционеры ставят задачу — добиться таких-то целей. И начинается внедрение даже без понимания того, что ИТ-система может не только пользу приносить, но и вред. Более того, вполне может быть, что организация в принципе не готова использовать тот или иной продукт, в ней работают такие люди, которым он просто противопоказан. Или степень зрелости компании такая, что определенные ИТ-продукты ей вредны.
Я бы в бюджет каждого ИТ-проекта закладывал предпроектное исследование особого вида. Готовы сотрудники к изменениям, которые их ждут? Примут они новую ИТ-систему или отторгнут, что бы команда внедрения ни делала? Возможно, в компании-заказчике есть проблемы, которые не позволят автоматизации сыграть ту роль, которую от нее ждут. Их нужно выявить до, а не во время проекта. Возможно, психологи, специалисты по работе с персоналом способны отвечать на такие вопросы. Можно выявить патологических противников любых изменений, можно найти тех, кому любая автоматизация помешает работать так, как он привык, поскольку уровень контроля станет совсем иным. Найдутся сотрудники, которым такой контроль совершенно невыгоден: если они всю жизнь работали без четких правил, то как можно автоматизировать их деятельность? Как минимум нужно вначале эти правила внедрить. Если их нет, то «жесткие» системы вызывают в организации шок.
То, что я видел в России, — это административный метод внедрения. Издается приказ: к такому-то числу система должна работать. Никто не понимает, зачем, почему должна, но все старательно делают то, что говорят им консультанты. Какой-то результат обычно получают. Но либо руководитель недоволен этим результатом, либо система стоит, а в ней никто реально не работает. Так что психологическая экспертиза могла бы принести большую пользу.
Опыт свидетельствует, что проблемы не в алгоритмах и не в технике, а в отношении к ИТ-системе. Можно отладить алгоритм, 15 раз объяснить всем, как нужно работать, и все равно на 16-й и 17-й раз кто-то будет ошибаться и говорить, что система не работает. Есть люди, которые этим просто спекулируют. Есть и другие — они четко понимают: ИТ-система позволяет им делать работу быстрей и качественней. Но они не пользуются ею, так как охраняют свое личное время. Если сделать задание быстро, так ведь потом еще навалят! Выгоднее твердить, что система не до конца доработана и вообще это непонятный черный ящик. Лучше оставить себе запас времени, чтобы уйти иногда пораньше, не в срок сдавать свои задания. Из этого тоже складывается неуспех проектов.
Другой важный компонент — консультанты. Возможно, есть специалисты, хорошо разбирающиеся в бизнесе, но я таких не встречал. Понятно, что человеку со стороны сложно прийти и сразу разобраться в чужом бизнесе. А ведь «дьявол в деталях», и если их не проработать уже на этапе составления ТЗ, не разобраться в них, то потом будет поздно. Поэтому, на мой взгляд, ИТ-проекты часто и дают обратный ход, признаются неуспешными.
Консультанты — как правило, люди с техническим бэкграундом. Они не понимают функционального языка заказчика. У них свой язык, «птичий». А ведь профессиональный консультант — это не тот, у кого масса сертификатов и обширные познания в технологиях. Это тот, кто может сидеть и слушать, что ему говорят, и стараться понять. Даже если ему это совершенно не нравится, он честно пытается разобраться в реальной потребности своих клиентов. Не понимает — идет читать книжку или привлекает специалистов из этой области, чтобы они ему вначале объяснили в чем дело, о чем речь-то идет. Ну наймите в штат двух классных финансистов, которые вам, разработчикам, растолкуют, что написали ваши клиенты в своем ТЗ! Да, у финансистов тоже свой язык, тоже «птичий». Но надо же переводить с одного «птичьего» на другой так, чтобы понимать друг друга.
В этом проекте я сам был переводчиком «с птичьего на птичий». И надо отдать должное нашим подрядчикам — они старались понять, хотя это было трудно. Они же считают себя специалистами в своей области, сделали уже много проектов. Но внутренняя способность слышать других — это навык, которого очень не хватает многим консультантам. Впрочем, надо сказать, что клиентам его не хватает тоже. Амбициозный менеджер часто пытается втиснуть в рамки проекта все, что только можно придумать. Причем понимания, как эта функция будет работать, у него чаще всего нет. И все равно «давай напишем, потом разберемся, что к чему».
Главное в проектном менеджменте — жестко держать рамки. Иначе все эти «не понимаю, как и зачем» потом выливаются в непонятные сроки, в невнятную стоимость, проект теряет определенность. Кто-то что-то сказал, какие-то распоряжения дал, что-то написано в ТЗ, но уже никто не знает, как с этим поступить. И тогда уже остается только тихо спускать дело на тормозах. Нельзя допускать в проект непонятные и непонятые вещи. Для этого требуется необходимый навык консультантов и заказчиков, их совместная работа.
Чаще всего проектные менеджеры фирм-консультантов не обладают знаниями в функциональной области. Ни в какой. График, план, запрос составили, на него ответили... только такая компетенция. Голый проектный менеджмент и больше ничего. Они считают, что их задача — свести вместе нужных людей, составить график работ, подготовить положенную документацию. Основная задача при этом — cover your ass, обеспечить процесс, а не получить результат. А нужны проектные менеджеры, разбирающиеся в предметной области.
Кроме того, если консультант излишне формализован (определенный уровень формализации, безусловно, необходим), то затраты клиента идут не на содержательную работу, а на документирование. Происходит перекос: клиент платит за то, что требуется только консультантам для обеспечения их работы, а по большей части — для их страховки.
CRN/RE: Как же определить необходимую степень формализации?
З.: Сколько нужно бумаг? В значительной степени это вопрос зрелости компании-клиента. Насколько работа в ней формализована? Насколько сотрудники привыкли отражать свои действия в документах? Насколько они готовы принимать правила и работать точно по ним?
В большинстве российских компаний, с которыми я сталкивался, вся работа ведется неформально. Формальные процедуры, конечно, есть, но они совсем иные, чем в западных фирмах. В российских организациях любой формальный документ — это приказ от батюшки-царя с подписью и печатью, и если не сделать то, что в нем написано, — «расстрел». Люди не осознают, что формализация нужна им же самим для наведения порядка. Как закон: осознанная людьми потребность поведения. Сотрудники должны осознавать, что этот стандарт, регламент необходимы им для работы, чтобы было легче и проще договориться. Пока же чаще всего любой документ принимается в штыки, считается, что это прессинг, давление, новое требование с непонятной целью.
В свое время я работал в KPMG и помню уровень организации процессов в этой компании. Все расписано, четко, понятно. И поэтому — просто. Конечно, структуризация процессов требуется бизнесу начиная с определенного уровня развития. Для компаний, не достигших его и не имеющих амбиций роста, автоматизация и формализация не окупятся.
В любом случае важно, чтобы и руководство, и сотрудники ясно понимали последовательность шагов: кто, когда и какие действия выполняет, суть этих действий, ответственные за них. Могут быть использованы простые средства: таблицы в Excel, например. Но все должны понимать единообразно, откуда берутся цифры в этих табличках, как они между собой соотносятся.
CRN/RE: Могут ли выдерживать разумный уровень формализации известные вам подрядчики? Насколько зрелы и структурированы их собственные процессы?
З.: Часто бывает так, что к нам приходят продавать, услышав одно знакомое слово. Скажем, BI. И тащат все, чем богаты. Говоришь им прямо: да не нужно мне это! Пауза. И опять все заново вываливают на тебя. Хочется просто встать и уйти с таких презентаций.
Надо признать, что у наших подрядчиков оказался довольно высокий уровень понимания того, как надо работать с бизнесом. Конечно, не без проблем. Очень часто ведь бывает так: мы взяли ТЗ, сделали то, что там написано, — все, до свидания. И формальные бумажки для этого и делаются. Для суда, грубо говоря. Продал товар и ушел. Это плохой подход. У нас таких случаев было достаточно. И мы оставались у разбитого корыта, получив недоработанную систему, с объяснениями, что мы сами виноваты, плохо объясняли задачу. А подрядчики продали нам недоделанный продукт и пошли дальше делать то же самое: такой тип поведения встречается во многих направлениях бизнеса, не только в ИТ.
И поэтому, несмотря на все разногласия, которые у нас с подрядчиками были, мне понравилось, что они за свой продукт отвечают. Они хотя бы всячески демонстрируют, что никуда не исчезнут. Системный подход, желание дорабатывать систему, даже если кто-то был неправ в постановке задачи, очень важны.