Рынок заказных программных продуктов в России, наверное, пока весьма далек от насыщения. Но количество выполненных проектов уже таково, что очередному корпоративному клиенту, в какой бы отрасли он ни работал, вполне можно — и нужно — присматривать для себя некий прототип в виде разработки, некогда выполненной для предприятия сходного профиля деятельности. Надо сказать, что на российском рынке уже появился некий класс решений, которые условно можно поместить между готовыми системами и заказными разработками. Соответственно и у заказчиков на опыте начинает складываться представление о том, как проводить комплексную оценку таких предложений.
Тендер необходим и достаточен
Департамент финансов Правительства Москвы и входящее в его состав Московское городское казначейство в настоящее время решают задачу автоматизации управления бюджетным процессом столицы. Эти работы предполагают создание ИС, которая осуществляла бы оперативный контроль информации, связанной с исполнением городского бюджета, а также аналитическую обработку этой информации, ее хранение и распространение.
Работы в этом направлении активно идут, но пока далеки от завершения. Однако уже сейчас ясно, что проект требует фактически полного спектра базовых технологий корпоративного уровня и богатого прикладного функционала.
Столь масштабные проблемы, стоящие перед крупными государственными организациями, в России традиционно принято решать с помощью заказного программного обеспечения. И в системе координат отечественного рынка образца 4–5-летней давности о проекте, решающем аналогичную задачу, наверное, можно было бы говорить исключительно как о заказной разработке. Сегодня ситуация изменилась, и решение, которое мы рассмотрим, как раз и относится к упомянутому выше «промежуточному» классу.
Началом целенаправленной деятельности по созданию специализированного решения для автоматизации бюджетного процесса можно считать подготовку к проведению тендера, начатую в конце прошлого года. Процесс выбора решения посредством организации тендера в России в последнее время привлекает все большее внимание, а значимость правильного проведения тендера для последующего развития проекта трудно переоценить. Вместе с этим тендерную процедуру в отечественной практике до сих пор трудно считать четко определенной.
В нашем случае также не обошлось без элементов субъективности, и следовательно, эту процедуру вряд ли можно трактовать как набор универсальных рекомендаций. Однако обратить на нее внимание в данном случае заставляет несколько причин. Во-первых, в соответствии со столичным законодательством проведение тендера было необходимой процедурой. Решение, о котором мы ведем речь, целевым образом финансировалось не только из федерального, но и из московского бюджета. Во-вторых, отношение заказчика к его выбору (и соответственно к проведению тендера) оказалось в высшей степени ответственным. "Приступая к выбору, мы хорошо осознавали, как важно не проиграть на самом первом этапе, — говорит начальник Московского городского казначейства Серафим Михайлович Ярных. — У нас так тщательно готовились тендерные предложения, так много было обсуждений критериев отбора решений и правил проведения тендера, что мы даже вышли за определенные нам распоряжением мэра сроки".
| Профиль клиента |
|---|
|
Компания: Местонахождение: Руководитель: Проблема: |
| Профиль партнера |
|---|
|
Компания: Местонахождение: Руководитель: Решение: |
Оценка решения в цифрах
Переходя к конкретике, хочется сразу начать с одного, на наш взгляд, очень важного критерия, который был выработан в процессе обсуждения методов оптимизации выбора системы. Четыре основных параметра, характеризующих предложения тех или иных фирм, были ранжированы в соответствии с их важностью для заказчика. Суммарный весовой коэффициент был взят равным единице; значения 0,4 были присвоены факторам, характеризующим качество решения, и его цене. С коэффициентом 0,1 учитывались комплексные предложения фирм-соискателей по обучению; значение 0,05 было присвоено фактору, отражающему финансовую устойчивость поставщика. Как видно, критерии формулируются предельно четко, имеют ясное количественное выражение, и кроме того, такой подход дает пищу для размышлений о перспективах решений, имеющихся сегодня на отечественном рынке вообще.
Отметим, что названные критерии носят общий характер и к тому же максимально "демократичны". Сами по себе они не создают условий для различного рода поляризации выбора — отечественные против зарубежных, заказные против готовых и т. д. Однако косвенные и, надо полагать, небезынтересные для отечественного читателя выводы на их основе сделать все-таки можно.
Сразу оговоримся, что момент начала проведения тендерной процедуры в строгом смысле не был стартовой точкой проекта. "Перед составлением технического задания наши специалисты довольно подробно знакомились с подобными системами, работающими в государственных организациях России, Казахстана, Германии, Англии, — говорит Серафим Ярных. — Одновременно с этим мы накапливали опыт, выстраивали концептуальную и технологическую архитектуру системы в наиболее общих параметрах". Итогом этой работы стал, в частности, ряд выводов относительно базовых технологий и функционала, которые должны были лечь в основу будущей системы. Неудивительно, что впоследствии в качестве таковых в тендере фигурировали программные платформы ведущих производителей, прекрасно известные во всем мире.
Что же касается прикладных программных продуктов, тендер показал, что разработки российских компаний по выдвинутым критериям действительно могут на равных конкурировать с продуктами зарубежных поставщиков. Окончательный список компаний-претендентов, сформированный после прохождения формальных квалификационных требований к участникам, оказался хоть и немногочисленным, но достаточно показательным. Соискателями оказались российская компания «Авикомп Сервисез», SAP СНГ, участвующая в тендере вместе со своими партнерами, а также выступающие в тандеме фирмы Borlas и Oracle. Оба последних альянса выставили на конкурс совместные решения, представляющие собой флагманские прикладные системы соответствующих зарубежных поставщиков, адаптированные их российскими партнерами. Как было отмечено, всем претендентам предстояло конкурировать в основном по двум параметрам — качеству решения и его цене. Что касается первого фактора, то, согласно формальному определению, это не что иное, как способность ПО адекватно справляться с решением заранее сформулированных бизнес-задач, при безусловной надежности сервиса базовой программной платформы.
| "Авикомп Сервисез" http://www.avicomp.ru |
| Компания создана в 1991 году, в настоящее время ее коллектив насчитывает более 100 высококвалифицированных сотрудников. "Авикомп Сервисез" предоставляет услуги по комплексной автоматизации деятельности организаций, созданию и интеграции информационных систем и их компонентов. При проектировании и разработке информационных систем компания ориентируется на комплекс методологий компании Oracle. "Авикомп Сервисез" имеет сертификат на соответствие деятельности организации международному стандарту качества ISO 9001. |
С базовым ПО дилеммы не возникло. Все представленные решения так или иначе базировались на платформе Oracle, апробированной в решениях для государственных и муниципальных структур как у нас в стране, так и за рубежом. Критерий качества прикладного ПО выкристаллизовался у заказчика в основном путем изучения российского и зарубежного опыта. И он, даже при столь небольшом числе претендентов (почти что модельной ситуации), оказался более вариативным. "Посмотреть решения, реализованные за рубежом, безусловно, было очень полезно, поскольку все организации, подобные нашей, в любой стране мира решают одни и те же проблемы. Пресловутая же российская специфика прежде всего связана с неустоявшимся российским законодательством", — говорит г-н Ярных.
И похоже (если судить и по описанным нами ранее проектам), что в случае автоматизации государственных структур изучение зарубежного опыта приносит реальную практическую пользу — в отличие, скажем, от автоматизации производства, где ответ на этот вопрос менее однозначен. В решениях, предложенных конкурентами «Авикомп Сервисез» в данном тендере, в качестве основы использовались зарубежные прикладные системы — R/3 и Oracle Applications, модернизированные в ходе выполнения последних заказов (в частности, в Казначействе Санкт-Петербурга и в Государственном Казначействе Республики Казахстан). Конечно, все это дает разработкам на базе данных продуктов дополнительный козырь. Количественный опыт, накопленный не за один год, у SAP и Oracle в данной сфере, безусловно, очень богат. А это и есть гарантии качества.
В этих условиях прикладные системы, полностью созданные отечественными разработчиками, могут конкурировать по критериям качества, используя пусть и не самый важный, но все же пока существенный фактор российской специфики. Для этого нужен все тот же опыт проектов, но уже на отечественном рынке. Важно также продемонстрировать еще ряд преимуществ, о которых мы скажем ниже.
Тот факт, что критерию устойчивости компании-соискателя был присвоен, прямо скажем, невысокий весовой коэффициент, скорее всего, отражает зрелость российского рынка корпоративного ПО. Иными словами, имеется возможность выбирать между устойчивыми и очень устойчивыми компаниями. И соответственно риски по данному параметру в любом случае невелики.
И, наконец, вопрос цены. Руководитель Московского казначейства говорит: "В конце тендера, когда члены комиссии вскрыли конверты с ценовым предложением и затем подсчитали общий балл, сразу выяснилось, что с довольно солидным отрывом победу в тендере одержала компания «Авикомп Сервисез". Сразу же скажем, что решение, предложенное SAP, как по качеству, так и по критерию финансовой устойчивости поставщика хотя и ненамного, но оказалось впереди остальных. И эта вполне реальная ситуация может служить практически идеальной моделью, демонстрирующей важность заключительного этапа тендера. Дело в том, что формальной процедуры оценки ценовых предложений даже в серьезных тендерах в России мало кто придерживается — по крайней мере в коммерческих организациях, где процедура выбора решений никем формально не регламентируется. Вместе с тем для объективной оценки всем известного параметра цена/качество решения необходима столь же объективная оценка каждой из двух его составляющих. Ценовыми характеристиками, как известно, можно «играть» в зависимости от складывающейся ситуации (в частности, перед началом проекта легче «спрятать» расходы последующих его этапов). В нашем же случае хорошо видно, что возможность отсечь подобные маневры может в случае комплексной оценки сыграть ключевую роль в выборе продукта.
Еще раз о качестве
Если для оценки ценовых характеристик решения в первую очередь необходима грамотно построенная процедура, то с качественными его характеристиками дело обстоит несколько сложнее. А то, что предлагаемые решения относились к не слишком типичной для местного рынка категории программных продуктов, привело к тому, что на первый план в их оценке вышли критерии, также пока не ставшие в России традиционными. И здесь можно было бы выделить по крайней мере две темы — проблему доработки функционала системы и обеспечение управления проектом. Обе имеют вполне общее значение.
"Знакомясь с предложениями претендентов, мы заметили одну общую для ряда из них черту, которая нас насторожила, — говорит руководитель Московского казначейства. — Не раз мы слышали заверения о том, что доведение функционала до того, чтобы он полностью удовлетворял нашим условиям, потребует не более 5—10% изменения уже имеющегося отлаженного программного кода". В этой связи стоит вспомнить, что даже в случае внедрения готовых продуктов корпоративного уровня такой процент доработки считается вполне приемлемым (если опираться на известное критическое отношение 80/20). В нашем же случае даже небольшое превышение декларируемой цифры создавало бы серьезные угрозы выполнению условий проекта. Доработка неизбежно выливается в дополнительные материальные и временные затраты. Условия же тендера однозначно определяли сроки проекта, равно как и невозможность в его ходе оказывать поставщику содействие, связанное с дополнительными материальными затратами.
То, что доработки потребуются, и достаточно серьезные, было ясно с самого начала. Но только сейчас, уже накопив определенный опыт внедрения, специалисты Московского казначейства утверждают, что при решении задач, подобных поставленным в данном проекте, и при нынешнем насыщении российского рынка делового ПО функционал требуемой системы должен быть дополнен по сравнению с имеющимся не менее чем на 25—30%. И уж коль скоро риски, связанные с программной доработкой системы, признаются неизбежными, то козырь теперь оказывается в руках “Авикомп Сервисез”. Компания прежде имела весьма значительный опыт автоматизации организаций финансового профиля (как коммерческих, так и государственных), и хотя бы по одной этой причине соответствующие риски можно было считать менее опасными. Основой представленного на конкурс решения была собственная разработка компании, выполненная ранее для Федерального казначейства и хранящаяся в соответствующем отраслевом Фонде алгоритмов и программ.
Опасения в связи с доработкой натолкнули заказчика на мысль включить в число обязательных требований к соискателям предоставление рабочей демо-версии продукта, и сейчас уже ясно, что это требование было отнюдь не лишним. Скорее наоборот: по словам руководителей проекта, все вышедшие на заключительный этап компании очень тщательно подготовились к тому, чтобы продемонстрировать собственные преимущества, в том числе и путем проведения демонстрационных показов. Это послужило одним из основных источников получения объективной информации.
Надо сказать, что действенность метода оценки решений с помощью демо-версий или требований от фирмы, предлагающей программное решение, разработать контрольные примеры, традиционно вызывала на рынке противоречивые мнения. Многим заказчикам (зачастую интуитивно) казалось, что подобные, пусть даже искусственные, способы приближения к реальности могут вскрыть то, что недосказано и недопонято в частных беседах и презентациях. Поставщики же (и это известный факт) к такой технологии выбора относятся откровенно негативно. И не только из-за ее ресурсоемкости и крайне невысокой результативности — она действительно оказывалась в принципе малоэффективной. В области заказных разработок создание демо-версии, в отличие от прототипа, вообще мало реально. В случае готовых решений основными преимуществами оказываются цельность, технологичность и апробированность всей цепочки внедрения — от методологии до конечных настроек продукта. Демонстрация фрагментов решения в этом случае технически осуществима, но практического эффекта не дает. На этом сходятся очень многие специалисты. И, быть может, выбор заказной системы на основе практически работающих прототипов — это тот случай, когда работа с демонстрационным ПО наиболее эффективна.
Необходимость доработки программного решения обостряет и еще одну универсальную проблему корпоративных проектов — управление ими. "Конечно, нас очень беспокоили вопросы сроков реализации проекта, а также вероятность возникновения дополнительных материальных затрат в ходе его выполнения, — говорит Серафим Ярных. — Оба этих критерия мы были вынуждены в условиях тендера четко определить. Но все равно названные проблемы неизбежно оставались факторами риска". Безусловно, требование к исполнителю указывать точное количество сотрудников того или иного профиля, которые будут впоследствии работать над проектом (как и ряд подобных условий), создавали определенную подстраховку. Однако полноценным инструментом снижения рисков должна была, по мнению заказчика, служить система управления проектом. Наличие собственной разработки этого класса также было одним из необходимых условий проводимого тендера.
Сам термин "управление проектом" столь же важен, сколь и расплывчат. К тому же его содержание зависит от конкретной ситуации. Согласно классическому определению, средство управления проектами (project management) представляет собой программно-методический инструмент, позволяющий выделить и оптимально распределить ресурсы (временные, людские и материальные) для решения определенной бизнес-задачи. В случае заказного программного проекта подобные задачи ставятся, как правило, "в чистом виде", а для поддержки планирования и отслеживания выполнения работ широко используются средства, подобные, например, Microsoft Project. Об этом неоднократно упоминалось и в наших публикациях, посвященных заказным разработкам.
В случае внедрения тиражируемых систем корпоративного управления эти задачи проектного управления трансформируются в более конкретные рекомендации, касающиеся выделения под проект сотрудников того или иного профиля, распределения их обязанностей, последовательности решаемых задач и, наконец, правил принятия и оплаты заказчиком этапов проекта. Многие из этих вопросов находят отражение в стандартных методиках, разработанных как независимыми консультантами, так и компаниями, поставляющими комплексные системы. А опыт внедрения тиражируемого ПО позволяет относиться к ним с известной долей доверия.
В рассматриваемом же случае мы снова имеем некую промежуточную ситуацию. С одной стороны, заказчик сталкивается с рядом проблем, характерных для заказного проекта. К ним, безусловно, можно отнести вопрос управления созданием документации, экспертизу которой проводит отдельная организация. В рамках проекта по требованию заказчика необходимо было использовать специально разработанную подсистему, позволяющую управлять документацией о ходе выполнения работ. Помимо Департамента финансов и компании «Авикомп Сервисез», в них непосредственно задействованы Государственное унитарное предприятие «Экономика» и Департамент экономической политики и развития Правительства Москвы. Если каждый из участников сможет вовремя получать необходимые документы, это в данном случае как раз станет инструментом снижения рисков.
Для заказных разработок также весьма типична проблема выхода исполнителя из проекта. По крайней мере, как утверждает руководитель проекта со стороны «Авикомп Сервисез» Михаил Васильев, впоследствии поддерживать разработку вполне сможет как сам заказчик, так и любая сторонняя компания.
Характерно, что необходимо было увязать рассматриваемый нами проект с рядом других, ведущихся в Департаменте финансов Правительства Москвы. По словам его руководителей, в организации в настоящий момент активно развиваются более десяти автономных подсистем автоматизации различных аспектов деятельности, различающихся технологически, но использующих в качестве источника данных единое хранилище. "На мой взгляд, управление проектом представляет собой многофакторный процесс интегрированного учета различных составляющих. Помимо мониторинга целого ряда параметров, непосредственно связанных с идущим проектом, необходимо управлять рисками и прогнозировать последствия в тесной взаимосвязи с другими работами, ведущимися в организации", — говорит Серафим Ярных.
Тот факт, что проблема внедрения системы (являющейся в значительной мере уже готовым продуктом) рассматривается в контексте всей инфраструктуры ведущихся в Департаменте финансов внедрений ИС, позволяет говорить о ведущихся работах еще и как об интеграционном проекте. И именно здесь в вопросах управления проектом необходим максимально индивидуальный подход. В данном случае проектные задачи уже не могут ограничиваться применением стандартных алгоритмов оптимизации выделяемых ресурсов (и соответственно стандартного ПО). И в то же время их пока еще не удается свести к набору рекомендаций, учитывающих квинтэссенцию «лучшей практики» накопленного в отрасли опыта автоматизации. Подобные обобщения существуют прежде всего у западных компаний, у которых была возможность накопить немалый опыт участия в сложных корпоративных проектах. Однако их применение оптимально, пожалуй, только в случае внедрения готовых подсистем. Примерно ту же мысль высказывает и руководитель Московского казначейства: "Технологию управления проектом можно было бы приобрести и у западного поставщика. Но я не раз видел, что даже в случае применения "умных" и толковых систем цели ставились некорректно, что сильно тормозило продвижение работ. Главное, на мой взгляд, чтобы и поставщик, и заказчик сфокусировались на индивидуальных особенностях проекта".
Подведем итог: рассмотрение ведущихся в Департаменте финансов работ позволяет сделать вывод, что появление на российском рынке проектов, сочетающих черты готовых систем и заказных разработок, способно привнести новизну во все стадии внедрения информационной системы.
| Московское городское казначейство |
| Создано в 2000 году с целью эффективного управления средствами бюджета Москвы в процессе его исполнения, повышения оперативности в финансировании городских заказов и программ, обеспечения оперативного контроля за своевременным зачислением доходов бюджета и целевым использованием государственных средств. Казначейство входит в состав Департамента финансов Правительства Москвы на правах структурного подразделения и состоит из функциональных и территориальных подразделений в административных округах. |
