«Коробочка» Пандоры

Как часто при общении с «бизнесом» или IT – представителями  крупных компаний приходится слышать гордое высказывание: «Это наше уникальное ПО. Есть только у нас, и мы его постоянно развиваем и дорабатываем!»

Мне подобное приходится слышать крайне часто, потому что являюсь ИТ-аналитиком, специализирующимся на развитии заказного (коробочного) ПО.

В этой статье я не ставлю глобальных целей описания пути внедрения и развития такого ПО (некоторые процессы ЖЦ я всё-таки опишу), а просто хочу поделиться опытом, который, возможно, будет полезен и интересен.

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

Что дальше? Сравнительный анализ рынка поставщиков услуг, анализа целей, возможностей, потребностей? Да не тут то было! Как правило, на этом этапе заказчик сильно экономит ресурсы (время, деньги и т.д.) и идет по пути наименьшего сопротивления. При этом выбор склоняется в сторону или уже находящейся на подряде небольшой фирмы, которая ухватится с удовольствием за предоставленную возможность еще немного обогатиться, или наиболее «распиаренного» игрока рынка по производству заказного ПО (во главу угла ставятся финансовые возможности организации заказчика). Важность этой стадии невероятна, и её влияние на будущее автоматизируемой области трудно переоценить. Заказчик находит себе партнера для создания чего-то уникального, и сравнение с семейной парой будет здесь вполне уместно.  Крайне необходимо познакомиться с исполнителем, понять, как именно он работает, соблюдает ли сроки, принципы программной инженерии, использует ли лучшие практики и госты в своей работе, понять, насколько подвержена выбранная фирма «текучести» кадров. Говоря кратко, тут не может быть не важных деталей. Если заказчик решит сэкономить на этой стадии, то впоследствии все эти «неважные» детали лягут дополнительным немалым грузом именно на его плечи, и все эти мелочи придется разгребать именно заказчику.

Благо, на отечественном рынке появляется все больше и больше организаций, реально соблюдающих и следующих передовым практикам и ГОСТам, но все равно абсолютная доля этих фирм несоизмеримо  мала, поэтому совет может быть только один: больше  общения с потенциальным исполнителем работ.

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

Приведу пример из жизни:  в одной корпорации РФ, в соответствии с информатизационной политикой этой самой корпорации, полагалось к 2012 году установить невероятно продвинутую, мощную, серийную систему электронного документооборота. Политика была составлена к 2007 году, и нашлась умная голова, которая решила запустить пилотный проект по созданию и внедрению системы электронного документооборота раньше (на 2009 г.) для того, что бы «потренироваться на кошках». Выбрали вендор, взяли от него платформу и «накрутили» на ней коробочный продукт, который «благополучно» внедрили и стали сопровождать. Начало сопровождалось плачевными результатами. Ураган недовольства, списание на это ПО разнообразных объективных и не очень проблем. Так продолжалось до самого 2012 года. К указанной дате работникам было объявлено, что систему будут менять. Поменяли… Прошло 3 месяца эксплуатации… И 99% работников взмолились о том, чтобы вернули старую систему. И дело тут не только в консерватизме человеческого сознания и в том, что ему всегда трудно привыкать к чему-то новому. Дело в том, что старое коробочное решение было объективно (по мнению не только исполнителей проекта, а многих приглашенных ИТ-специалистов и аудиторов) производительнее, быстрее, и «что ли  человечнее» (прямая речь топ-менеджера компании).

Так же, на мой взгляд, интересен будет западный пример внедрения коробочных продуктов. Дело происходило в 2010 г. в Чехии. В  финансовой компании было решено разработать и внедрить коробочный продукт, отвечающий за централизацию и унификацию платежных поручений. Продукт разработали и начали период пробной эксплуатации. Сотрудница, работавшая на этом участке работ (женщина 49 лет) встретила в штыки его внедрение. С сотрудницей было проведено порядка 3 бесед самим генеральным директором (фирма не маленькая, на тот момент она насчитывала около 1500 т. работников). В процессе этих бесед руководитель терпеливо объяснял своей рядовой подчиненной о том, что она важна для компании (стаж её работы в компании на тот момент составлял 15 лет), но и ПО имеет стратегическую важность для развития их бизнеса. В результате —  сопротивление работницы преодолеть не удалось и её, банально, уволили. Причем, по словам коллег, это не единичный случай, а довольно распространенная практика для западных ИТ компаний.

В общем сказка сказывается, а конкретики-то в статье не хватает, поэтому привожу сравнительную таблицу. Для неё мной за основу взяты этапы технических процессов из ISO/Гост 12207. Просто на мой субъективный взгляд это наиболее качественный продукт описывающий инженерию ПО (ну и SWEBOOK, конечно). Я выбрал 4 процесса наиболее показательных при внедрении и развитии ПО:

• Анализ системных требований
• Проектирование архитектуры системы
• Процесс реализации
• Процесс сопровождения программных средств

Увеличенная версия таблицы.

Выводы из всего выше написанного поражают своей гениальностью и внезапностью:

1. Есть возможность автоматизировать область за счет серийного продукта – делайте. Все остальное, не являющееся серийностью будет уникальностью, а уникальность, как известно, стоит дорого, причем чем более длительное время Вы её используете, тем дороже это будет стоить.
2. Личное участие топ руководства в проекте является необходимым условием его успешного завершения
3. Квалификация персонала, задействованного в проекте. На проекте не должно быть слишком много высококвалифицированного персонала. В каждой области должен быть один мозг и набор высококвалифицированных исполнителей. Причем высокая квалификация «мозга» это, прежде всего, не способность придумать что-то этакое, а способность обеспечить качественную базу знаний по своей предметной области на проекте и наследственность опыта, с тем, чтобы в любой момент тот, кто придет за ним, смог бы обеспечить дальнейший беспроблемный ход проекта.
4. Разработка, внедрение, развитие, сопровождение проекта в соответствии с лучшими практиками, ГОСТами т.д. Чем более полно и качественно это отстроено, тем большие дивиденды получит бизнес.
5. Не пытаться объять необъятное. У каждого ПО есть своё назначение и список задач, которое оно должно закрывать. Навязать новые, дополнительные задачи на Ваше коробочное ПО, порой может принести только беды в его обслуживании. Если это система электронного документооборота, то не следует путать её с архивом, если это система автоматизации страховой деятельности, то осуществлять в ней бухгалтерские проводки не следует. В таких системах резко повышается возможность возникновения ошибок, а ответственных за бизнес процессы интеграции смежных областей потом днём с огнём не найдёшь. Эти «сквозные» процессы являются точкой преткновения во многих компаниях.
6. Коробочное заказное ПО – это невероятно тонкий инструмент (что-то типа стамески для вырезания фигурных кружев). Этот инструмент должен служить по назначению и выполнять круг поставленных задач. За ним должен быть соответствующий уход. Не пытайтесь ей забивать гвозди, возьмите лучше молоток.

Автор:

Иван Никитин

Бизнес-аналитик с 8-летним стажем.