 |
| Евгений Зиндер: «Наибольший риск лежит в области внедрения прикладных пакетов, например систем управления предприятием» |
Подобная «зависимость» стала ключевым словом в названии круглого стола, проведенного в рамках форума «Интеллектуальное предприятие ?99» издательством «Открытые системы» — «Проблема зависимости Заказчика от Исполнителя при внедрении, использовании и развитии системы автоматизации предприятия».
Поэтому, открывая дискуссию, ведущий круглого стола Евгений Зиндер, директор аналитического и конструкторского бюро «Группа 24» и куратор рубрики «Директору ИС» нашего еженедельника, сосредоточился на областях наибольшего риска, который лежит в сфере внедрения прикладных пакетов, например систем ERP. При этом складывается два вида зависимости: от пакета как такового и от исполнителя, зашивающего в систему в процессе ее внедрения определенные настройки.
 |
| Владимир Галас: «На российском рынке при очень хорошем — для заказчика — контракте не так-то просто заинтересовать исполнителя» |
Риски обусловлены объективным изменением потребностей заказчика в процессе развития, с которыми исполнитель не сможет в силу ряда причин справиться. С другой стороны, если отказаться от услуг внешних разработчиков, можно попасть в зависимость от собственного персонала, что на деле может быть даже хуже.
Обсуждение заставило по-иному взглянуть на проблему взаимоотношений заказчика и исполнителя, увидеть в ней более глубокие пласты, чем прямая зависимость.
Не секрет, что многие ораторы склонны обострять проблему, иные же стремятся превратить в рапорт любое публичное выступление. Но, возможно, именно нетривиальный и эмоциональный подход и требуется при обсуждении столь сложной темы.
Прямое попадание… в зависимость
Так или иначе, в таком обсуждении важно не рассматривать результаты автоматизации крупных предприятий с полярных позиций. Это неоднократно подчеркивали участники круглого стола. Так, по признанию Бориса Петровича Мироненко, начальника управления информационных технологий и автоматизации Сибирской нефтяной компании, отрицательный опыт, полученный при общении с первым поставщиком, позволил компании выстроить разумную линию поведения со вторым.
В состав «Сибнефти» входят Омский нефтеперерабатывающий завод и Ноябрьское газодобывающее предприятие. При этом только Омский завод — это на самом деле пять заводов, он покрывает территорию в 30 кв. км, и работает на нем 9 тыс. человек.
Автоматизация здесь началась в 1989 году, причем компания пошла по нестандартному пути — на первом этапе появились системы управления технологическими процессами, а не система управления предприятием. Иными словами, сначала появились системы, содержащие те данные, которые могут в дальнейшем участвовать в управлении предприятием. Акцент был сделан на встроенные системы. К реализации привлекались разные исполнители, но «роднит» их системы то, что они по существу, являются уникальными, закрытыми и в общем-то малораспространенными продуктами. И сейчас, хотя с начала работ прошло десять лет, компания по-прежнему зависит от весьма жестких условий соглашения с таким монополистом, как АBB.
Следующим шагом в автоматизации, повлекшим необходимость принятия еще одного стратегического решения о выборе поставщика, стало создание единой информационной системы. После длительного анализа в 1995 году было заключено соглашение с SAP о поставке системы. Учитывая сложности, возникавшие в управленческом учете в связи с масштабами и территориальной рассредоточенностью компании, было принято именно такое решение. При этом руководство «Сибнефти» решило в работе с SAP придерживаться своего собственного «стиля».
Чтобы не попасть в чрезмерную зависимость, было решено уделять особое внимание обучению собственных специалистов. У «Сибнефти» затраты на эти цели составляют 15% общей стоимости работ. Обучение проводилось одновременно с выполнением самих работ. В итоге нефтяники «воспитали» довольно мощную команду специалистов по R/3. При этом руководству надо было позаботиться о том, чтобы специалисты такой высокой квалификации оставались на предприятии. Для этого, в частности, поддерживалась высокая степень специализации каждого работника: учитывая ограниченную распространенность этих систем, такому сотруднику будет нелегко найти новое место работы.
Следующий важный момент — выбор платформы. «Сибнефть» остановилась на платформе Hewlett-Packard. Надо отдать должное сотрудникам HP — они провели полный курс обучения для специалистов «Сибнефти», а при наладке не «закрывали спиной мониторы», как это нередко делают специалисты крупных консалтинговых фирм.
Как автоматизировать вселенную?
По словам Вячеслава Шолохова, главного инженера департамента информационных ресурсов Министерства РФ по налогам и сборам, ему выпала очень трудная задача: «Рассказать об автоматизации функциональной деятельности налоговой службы и ее подразделений, представляющей собой сложную, территориально распределенную, многоуровневую информационную систему государственного значения, и про взаимоотношения заказчика и разработчиков в процессе ее создания, за такое короткое время — все равно что рассказать про всю вселенную».
 |
| Борис Мироненко: «Отрицательный опыт, полученный при общении с первым поставщиком, позволил компании выстроить разумную линию поведения со вторым» |
Это трехуровневая система, состоящая из федерального, регионального и местного уровней. Федеральный уровень представляет центральный аппарат министерства, региональный уровень — 90 инспекций, местный уровень — 2691 инспекцию.
Закупки технических средств, телекоммуникационного оборудования и системного программного обеспечения осуществлялись на конкурсной основе в соответствии с установленным порядком. Разработчиком централизованных программных средств прикладного функционального назначения для министерства является его Главный научно-исследовательский вычислительный центр.
На первом этапе создания системы разработчик в Госналогслужбе исполнял в то же время и роль заказчика. В связи с этим необходимая техническая документация на разработку отсутствовала.
Была сформулирована задача улучшения качества разработки программных средств, централизация их разработки и создание системы АИС «Налог». В настоящее время в налоговых органах происходит переход на новый этап работы с налогоплательщиком: с одной стороны — упрощение структуры документов, поступающих от налогоплательщика, с другой — упрощение процедуры их приема и проверки.
Постоянно происходит развитие системы. В процессе эксплуатации возникает масса новых функциональных задач.
Для улучшения качества разработки программ заказчик при взаимодействии с разработчиком должен отслеживать выполнение двух требований: первое — обеспечить высокое качество документации на разработку, второе — обеспечить должный уровень организации и проведения приемки программных средств.
При взаимодействии с разработчиком выявился ряд проблем с точки зрения разработки документов. Во-первых, ТЗ на разработку функциональных задач в большинстве случаев делалось только для того, чтобы открыть работу. Во-вторых, большинство пунктов ТЗ носили декларативный характер. Поэтому разработчику затруднительно было составить полную программу и методику испытаний, а заказчику по ней принять программное средство. В результате члены комиссии по приемке просматривали, по существу, экранные формы, а ТЗ на разработку комплекса задач не выполнялось.
Многие задачи приходилось принимать по описанию постановки задачи. В ней отсутствует раздел требований и дается описание лишь характеристики самой задачи, входных/выходных документов. Разработчику выгодно сдавать программу по описанию постановки задачи — там нет требований. Разработчик всячески старался производить именно такую сдачу, и представители заказчика активно боролись с этим.
Параллельно с разработкой функциональных программных средств осуществлялось создание «Системного проекта», с тем чтобы отойти от позадачного ведения проектирования. «Системный проект», с одной стороны, позволял представить архитектуру системы, произвести ее декомпозицию на подсистемы и программные комплексы для каждого уровня, а также выделить межуровневые комплексы. С другой стороны, он задавал бы четкий план разработки и соответствующий сетевой график работ. Тот, кто имеет опыт разработки подобной системы, знает, что план информатизации при позадачном подходе может вырасти до многих томов. При этом бывали случаи, когда разработчик под разными предлогами включал в план информатизации одни и те же по функциональному назначению задачи, но под различными формулировками, что приводило к дублированию.
Поэтому в план информатизации на 2000 год было решено включить программные средства только на уровне подсистем и системы в целом, с учетом этапности их разработки и доработки ТЗ по разделу требований. При этом вся документация на разработку программных средств должна быть взаимоувязана на основе ГОСТов.
Проведенный системный анализ функциональных задач в АИС «Налог» показал, что на местном и региональных уровнях можно создать такую оболочку, которая бы позволила централизованно сосредоточить в себе общесистемные функции, общие для многих задач, предоставить программные стыки для функциональных задач и тем самым предоставить возможность работы функциональным ПС в среде данной оболочки. После выделения из общесистемной оболочки части, касающейся централизованного ввода, регистрации и контроля информации, можно организовать специальные центры обработки данных. Этот путь и был выбран заказчиком.
В настоящее время работы по модернизации АИС «Налог» возглавляют заместитель министра Михаил Мишустин и руководитель департамента информационных ресурсов Александр Иконников.
По мнению Шолохова, для того чтобы прийти к желаемому результату — созданию системы, заказчик должен располагать специалистами, которые знают, что они заказывают, могут детально разобраться с тем, что делает разработчик, и оперативно вести с ним работу.
Слишком хорош, чтобы…
Интересно, что тщательная проработка юридических тонкостей договора с поставщиком может обернуться своей противоположностью. В качестве примера руководитель департамента АСУ группы компаний «Май» Владимир Галас сослался на собственной опыт. Более чем двухлетняя работа, которая опиралась на грамотно составленный контракт и которой предшествовал проведенный на высоком уровне тендер, привела к парадоксальному заключению: лучше бы контракт был «похуже» для заказчика. Оказывается, на российском рынке очень мало компаний, которые были бы способны длительное время работать на высоком уровне. Это требует от исполнителя огромных затрат, и, не получая компенсации за «неожиданно» большой объем работ, он старается «бегать» по новым клиентам, «снимая с них сливки». На российском рынке при очень хорошем — для заказчика — контракте не так-то просто заинтересовать исполнителя.
В компании «Май» делали попытки разными способами решать эту проблему. Казалось бы, чего проще для достаточно богатой компании перекупить специалистов у разработчика и получить таким образом практически полный контроль за ходом проекта, но одним из важных выводов, в частности, стало то, что специалисты по внедрению систем, будучи оторванными от своей «альма матер», быстро теряют квалификацию и тот опыт внедрения и использования продукта, который, собственно, и важен для заказчика.
Взаимопонимание, а не зависимость
Значение контракта во взаимоотношениях заказчика и исполнителя подчеркнула Светлана Рыбак, представитель коллегии адвокатов «Мосюрцентр». И хотя, возможно, на бытовом уровне юрист для многих — это человек, обладающий специальным умением говорить совершенно непонятно, Рыбак предложила отвлечься от тонкостей составления контракта и обратила внимание на то, что один из источников проблем — это непонимание между заказчиком и исполнителем. По ее словам, исполнитель нередко пользуется этим непониманием, тем более что, как правило, уровень его квалификации более высок, чем у заказчика.
Проблема, с которой сталкивается любой консультант по правовым вопросам, — заказчик немного недоговаривает. Юристу, которого привлекают на стадии подготовки, недодают информации, считая, что ему это не нужно: зачем-де правоведу знать какие-то технологические вопросы? В результате очень важные нюансы не находят отражения в договоре.
Кроме того, прежде чем заказчик будет формулировать задания для своих сотрудников или для привлекаемых специалистов, он сам для себя должен решить, что он хочет получить в результате. Когда исполнитель говорит, что, скажем, в течение пяти лет систему не надо будет трогать, а потом, скорее всего, потребуется небольшая переделка, необходимо спросить его, почему он так думает. Иными словами, надо сформулировать его ответственность.
По словам Рыбак, это нашло выражение в применяемой юристами практике — заказчик должен простым бытовым языком описать, что, собственно, ему требуется. Эта бумага становится основой для выработки юридически корректного договора.
Впрочем, сформулировать только желаемый результат недостаточно. Нельзя ссылаться лишь на нечетко сформулированное ТЗ. Галина Волкова, профессор ИКТИРАН-МГТУ, провела аналогию с машиностроительным производством. Там есть не только ТЗ и готовый продукт, но между двумя этими точками — два модельных представления, которые называются конструкторской и технологической документацией и которые хотя и предусмотрены (аван-проект, технический проект, рабочая документация), практически всегда опускаются в информационных системах.
Есть зависимость — есть результат
При внимательном рассмотрении проблема зависимости может обернуться неожиданной стороной. Руководитель отдела корпоративных продаж Cognitive Technologies Сергей Сухоцкий видит два типа зависимости. Помимо зависимости в традиционном понимании, имеющей отрицательную окраску, есть и другая зависимость, когда исполнитель сам побуждает заказчика создать действительно эффективную систему.
В этом отношении полезно проследить недалекую историю рынка. Когда он лавинообразно развивался, многие исполнители стремились продать проект и освободиться от заказчика совсем. При этом их мало волновало, работает в итоге сданная система или нет. Сейчас уже рынок более жесткий и приходится работать на результат. В этом отношении беспокоиться стоило бы скорее об отсутствии зависимости, которая может служить индикатором качества продукта.
 |
| Вячеслав Шолохов: «Для того чтобы прийти к желаемому результату — созданию системы, — заказчик должен располагать специалистами, которые знают, что они заказывают» |
Если же отношения заказчика и исполнителя развиваются в течение продолжительного времени, проблемы зависимости как таковой не существует. Может существовать недоговоренность — отсутствие понимания — с заказчиком. Значит, не построены целостные отношения, не отработана процедура, позволяющая договориться о том, как система должна быть сделана.
С этой точки зрения взаимоотношения между заказчиком и исполнителем нельзя рассматривать в контексте «кто прав, кто не прав». Важна цель. А она либо состоит с том, чтобы проект работал и приносил реальные результаты, и в этом случае, как правило, стороны обо всем договариваются, либо цель смещена в сторону и заказчик ставит своей целью «навесить» на исполнителя побольше работы за меньшие деньги, а исполнитель ставит целью уменьшение количества работы в рамках суммы контракта. Опыт показывает, что ведение проектов непростой процесс, и иногда техническое задание меняется на все 100%. Необходимо заранее договориться с заказчиком о каких-то уступках в ту или в другую сторону. Тогда заказчик подключает свои силы, силы тех управлений, которые будут реально эксплуатировать систему, и они выступают экспертами в этой области, а исполнитель создает проект. Просто все готовы к доработкам и уступкам ради конечного результата.
Вопрос зависимости от поставщика — это еще и вопрос надежности поставщика. По мнению представителя IBM Михаила Башелеишвили, цикл жизни местных российских компаний наиболее велик, когда это «нишевые» компании. Конечно, нельзя категорично рекомендовать выбирать тех поставщиков услуг, которые ограничивают себя рамками узкой рыночной ниши, и, наоборот, не рекомендовать пользоваться услугами тех, кто обещает сделать все что угодно. Тем не менее налицо факт, что компании, которые выбирают нишу, живут дольше.
Просто честные отношения
Говоря о роли консультантов, Сергей Колесников заметил, что время, когда поставщик «образовывал» покупателя, как бы поднимал его вверх, прошло. В какой-то момент произошел катастрофический разрыв, покупатель «резко пошел вверх». Потребности клиента стали значительно больше того, что поставщик может предложить. Отсюда возникли проблемы, связанные с необходимостью создавать свой коллектив исполнителей. Отсюда возникла ситуация, что системы все-таки создает заказчик, который оказывается, хотя бы на очень высоком уровне, постановщиком задачи. Именно в этом случае проект развивается более или менее регулярно, потому что заказчик сам понимает, как он развивается. Поставщик не может следить за проектом, и, если заказчик тоже за ним не следит, проект оказывается в свободном плавании. Некоторые поставщики, правда, уже это поняли и стали принимать адекватные меры.
Неспособность исполнителя «держать» очень крупные проекты оказывается еще одним аспектом, осложняющим взаимоотношения исполнителя и заказчика, вызывающим досадное ощущение зависимости. А объясняется это отсутствием вторичного рынка ресурсов. На это обратил внимание Михаил Донской, генеральный директор компании «ДИСКО». Вопрос в том, кто будет заниматься интеграцией.
Донской убежден, что аутсорсинга у нас, к сожалению, «нет как класса». А нет его потому, что, в свою очередь, напрочь отсутствует понятие репутации разработчика. Существующие отношения между заказчиком и исполнителем имеют иногда очень опосредованное отношение к разработке. Они скорее напоминают брачные отношения. Весь круг потребностей ни одной мало-мальски крупной организации покрыть нельзя. Рано или поздно заказчик поставит перед исполнителем задачу, которую он, как честный человек, должен будет передать.
Как бы то ни было, мнение Донского в наиболее яркой эмоциональной форме указывает на важный аспект проблемы взаимоотношений заказчика и исполнителя, а именно что к ним надо относиться с тех же позиций, что и к обыденным человеческим отношениям. В корпоративной сфере точно так же действуют такие вечные критерии, как честность и искренность.
Резюме
Задачу подвести итог дискуссии взял на себя Евгений Зиндер, попытавшись придать ему форму конструктивного рецепта. Он предложил:
- обеим сторонам признать объективное существование взаимной зависимости заказчика и исполнителя;
- описывать проявления этой зависимости как факторы риска проекта;
- явно распределять ответственность за риски зависимости и управление ими между сторонами;
- включать описание этого распределения в контракт.