Современная тенденция создавать систему «под себя» путём развития покупной заготовки распространяется среди тех покупателей, которые осознали, что бизнес-процессы будут меняться постоянно и за следующие после внедрения три-пять лет на их предприятии накопится очень большой объем изменений. Во многих случаях удобнее и дешевле использовать готовую платформу и готовых специалистов, хорошо в ней разбирающихся. То есть создавать систему «своими силами», но уже на принципиально новом уровне.
Владимир Галас
Директор
компании «Бэнто»
Прежде
всего при создании ИС предприятие сталкивается с проблемой выбора: «все работы
отдавать поставщику услуг» или «всё делать своими силами»? Это два крайних полюса,
условно их можно назвать северным и южным. И если в 90-е годы симпатии компаний
были явно ближе «к югу», то в начале 2000-х их «качнуло на север». Сейчас же
опять наблюдается явная тенденция движения «на юг», но уже совершенно на другом
уровне.
Объясняется это довольно просто. В начале 90-х годов казалось, что возможно всё. Наблюдался подъем и в общественной жизни, и в программистской среде. Было опьянение возможностью разработать систему, в которой очень хорошо можно организовать интерактивную работу пользователя. Каждая более-менее приличная фирма вне зависимости от сферы деятельности имела в штате своих разработчиков, которые верили в возможность создания системы не только для себя, но и на продажу. И не просто верили, а изо всех сил пытались реализовать свои мечты.
Потом, где-то к концу 90-х, они поняли, что разработка системы своими силами при всей потенциальной гибкости в реализации не лишена проблем. Причем таких, которые все чаще заставляли отказываться от «самодельных» продуктов. На создание необходимой бизнесу прикладной системы, даже на основе самой современной технологической платформы, уходят годы. Не у каждого есть столько времени и терпения. Да и огромная зависимость от своих сотрудников, создающих по сути уникальный продукт, — перспектива не очень светлая. При выборе, например, автомобиля предпочтение отдаётся не уникальной модели, собранной в гараже, а серийной, в построение которой вложены средства, какие ни одному даже вполне состоятельному клиенту и не снились.
Все
это привело к тому, что в начале 2000-х годов проявилась обратная тенденция
— преимущественного использования готовых продуктов и обращения к специализирующимся
на них компаниям. Собственно это была общемировая тенденция, в каком-то смысле
свидетельствовавшая о «взрослении» российского рынка.
Рынок осознал, что время — это и вправду деньги. Появились фирмы, готовые хорошо заплатить за быстрое внедрение, которое полностью исключает «индпошив» и сводит к минимуму серьезную подгонку под особенности бизнеса.
Но... и на этом пути нашлись серьезные проблемы. Первая — специфическая: изменчивость
условий бизнеса в России на уровне выше среднего. Вторая — универсальная: конфликт
интересов продавца и покупателя. Продавец заинтересован в увеличении количества
продаж, что крайне отрицательно сказывается на качестве конкретных проектов.
Покупатель же заинтересован в качестве проекта и его постоянном развитии, что,
в свою очередь, крайне отрицательно сказывается на проектном бюджете.
Сейчас многим предприятиям стало понятно, что для создания собственных ИС гораздо
удобнее и дешевле использовать готовую прикладную платформу и готовых специалистов,
разбирающихся в ней, но при этом производить ее доработку на протяжении всего
срока владения. Такой подход аналогичен собственной разработке, но стоит уже
на качественно новом уровне. Жизнь заставила компании перейти к модели «сделай
сам, но с помощью профессионалов», точнее — «сделай с помощью профессионалов,
но сам».
Объективность последующих
доработок
Все согласны, что какая-то настройка и даже доработка купленного продукта нужна
и делается всегда, хотя бы для выдачи дополнительных отчетов. Однако, на мой
взгляд, доработка типового продукта — куда более многогранный и глубокий вопрос.
Предположим, продукт выбран, договор заключен, стартовый проект «кастомизации»
и ввода системы в действие завершен. Но затем выясняется, что вместе с развитием
организации необходимо развивать и ее бизнес-процессы. Каково бы ни было внедрение,
что бы ни внедрялось — готовая или собственная разработка, — нужно хорошо понимать,
что бизнес-процессы будут изменяться. Поэтому никогда нельзя считать, что старт
новой системы — это конечная точка. С развитием бизнес-процессов возникнет частичная
реализация этих функций в системе. Но это никого не устраивает. Надо параллельно,
а возможно, и опережающими темпами развивать и дорабатывать ИТ-систему. Причём
проблемы нужно решать очень быстро. Ждать несколько лет, когда будет готов необходимый
продукт, невозможно.
Но вот договор на внедрение системы закончился, и у поставщика услуг внедрения больше нет особого резона работать с компанией. Что делать, заключать новый договор на развитие системы? Но объем работ, приходящихся на каждый очередной квартал или месяц, гораздо меньше, чем в стартовом проекте, соответственно меньше должна быть и стоимость работ. При этом выполнять их надо быстро, все время сохраняя погруженность в особенности организации. Это гораздо менее выгодно для поставщиков услуг, возможно, поэтому они во многих случаях так резко теряют интерес к своим клиентам после внедрения системы.
А кроме того, неужели теперь вы связаны с ним навсегда?! В голову лезут мысли
типа: «посадили на иглу»! Далее часто следует переманивание компанией-заказчиком
специалистов поставщика или активный поиск соответствующих работников на внешнем
рынке. И то и другое ведет к стремительному подорожанию собственной рабочей
силы заказчика, но не всегда приводит к успеху.
Даже при таком поверхностном взгляде видно, что надо детальнее разобраться в
коренных причинах потребности в развитии системы. В какой мере и почему она
должна будет расти? Насколько большим может быть объем доработок, как его распределять
во времени, каким образом нужно дорабатывать приобретенную программную часть
системы, на каком этапе внедрения и эксплуатации это делать?
Динамика расходов на ИТ-систему
На качественном уровне динамику изменений и доработок ИТ-системы можно представить
графически (см. рисунок). Ось «Время» градуирована по месяцам, а ось «Деньги»
— в некоторых условных единицах. Здесь можно выделить три четко выраженные зоны.
Первую условно назовём «зона договора». Это время, требуемое на внедрение
ПО, время действия договора на внедрение. Данная зона и есть тот срок, который,
как правило, объявляется поставщиком в коммерческих предложениях. Настройка
продукта под клиента — это работы, выполняемые как стартовый проект ввода системы
в постоянную эксплуатацию. Преимущественно (на 80—90%) они возлагаются на внешних
консультантов.
Динамика расходов на создание и развитие системы
Вторую условно можно назвать «зона компромисса». Это время доработки
системы по мере осознания своих потребностей. Иначе говоря, работы, вызванные
не новыми потребностями, а изначальными, которые не были высказаны представителями
заказчика внешним консультантам и распознаны ими. Причем без какого-либо умысла
со стороны каждого из них (консультант: «Что же вы мне в свое время не сказали?»;
заказчик: «Я же не мог представить, что можно будет...»). Это те самые вопросы,
которые обычно решаются между заказчиком и поставщиком услуг, внедряющим продукт.
Опыт многих организаций показывает, что объем доработки по мере осознания может
быть несколько меньше, но он сравним с объемом адаптации прикладного пакета
в стартовом проекте.
За чей счет будут проводиться эти доработки? На данном этапе теряется заинтересованность
внедряющей компании, потому что формально все зафиксированное в договоре выполнено.
Чаще всего именно здесь возникают нереализованные проекты. Конечно, многое зависит
от опыта и квалификации договаривающихся сторон. На практике встречаются разные
ситуации по юридическому оформлению обязательств, но без взаимной заинтересованности
результатов скорее всего не будет, поэтому здесь неизбежен какой-то компромисс.
Если компромисс находится, то проект реализуется. Если нет — как правило, объявляется
неуспешным.
Третью зону можно назвать «зоной преимущественно самостоятельной работы».
В это время ведётся поддержка изменений бизнес-процессов — работы, вызванные действительно новыми потребностями, которых не существовало при выполнении проекта внедрения. Когда программный продукт уже внедрен, возникают новые потребности, происходит реструктуризация бизнеса или изменение внешних условий. В результате — очень большой объем необходимых доработок. Как бы ни была хороша программа, как бы ни были прекрасны отношения с поставщиками услуг внедрения, это объективный фактор. Работы по поддержке изменений бизнес-процессов будут складываться из изменений их логики, из изменений в потоках работ и маршрутах документов, из изменений отдельных бизнес-правил и элементов данных, из связанных с ними изменений в экранных формах и печатных отчетах и даже из простого изменения экранов для большего удобства пользователей и из появления новых или изменения старых отчетов. Кроме того, есть работы по интеграции прикладных систем и их частей.
Каков же объем этих изменений? Многие такие работы взаимосвязаны, поэтому попытка хотя бы только на качественном уровне экспертным путём оценить объемы изменений каждого типа в отдельности не очень полезна. На мой взгляд, для многих организаций объем работ по поддержке изменений бизнес-процессов за три-пять лет, последующих за стартовым проектом, может превышать, причём иногда значительно, объем стартового проекта.
Наверное, можно сказать, что современная тенденция создавать систему «под себя» путём развития покупной заготовки распространяется именно среди тех покупателей, которые поняли, что бизнес-процессы будут меняться постоянно, так что всего за несколько лет накопится очень большой объем изменений.
Самостоятельное развитие системы
Именно в третьей зоне, с моей точки зрения, кроется основная причина того, что возникает необходимость использовать готовое ПО и развивать его самостоятельно. Конечно, такие доработки можно отдать и на аутсорсинг, но в очень многих случаях гораздо целесообразнее 80—90% работ из этой зоны выполнять своими силами. Не взяв их на себя, предприятие будет вынуждено тратить деньги, вполне сопоставимые с затратами на внедрение. Договор идет за договором, вот и получается, что компания «садится на иглу».
Естественное стремление к минимизации этих затрат — это создание необходимой компетенции у себя в ИТ-отделе и стремление выполнять львиную долю таких работ самостоятельно. Лучше все это предвидеть заранее и создать собственную «группу развития системы» одновременно со стартовым проектом, как это сделали в свое время, например, в компании «Мерлион» для автоматизации своей деятельности. Более того, начиная уже со второго проекта внедрения нового прикладного продукта (всего проектов было довольно много) работы в этой компании выполнялись практически силами своих сотрудников. К тому же эта группа обеспечивала развитие уже эксплуатируемых систем путём доработки.
Естественно, при таком подходе к развитию системы есть и отрицательные моменты. При наличии сильной команды собственных разработчиков большие риски могут возникать при длительном сопровождении и развитии системы, сделанной даже на основе добротной прикладной платформы-конструктора. При масштабных, а главное — глубоких, т. е. затрагивающих функции ядра системы доработках существует риск остаться без помощи «большого брата» в лице разработчика продукта, т. е. практически без перспектив перехода на новые версии. Отчасти этот риск можно уменьшить за счет приобретения качественного прикладного ядра и строгого запрета на его изменения в ходе самостоятельного развития системы. Ядром может быть хорошо продуманная прикладная база данных, плюс модуль учета основных профильных данных (например, тот же бухучет или кадры), плюс набор совместимых элементарных прикладных функций (конструктор), плюс язык сборки из элементов этого конструктора, плюс механизмы установления интерфейсов с добавляемыми функциями и внешними сервисами и, конечно, средства управления транзакциями, доступом к данным и т. д. Но и в таком случае смена версии ядра исходной прикладной системы может требовать от компании немалых затрат на перенос всех своих доработок на новое ядро.
Кстати, в результате такого подхода к самостоятельному развитию системы события могут развиваться и по другому сценарию. В компании собирается приличная команда разработчиков, и появляется соблазн не только удержать высококлассных специалистов «при себе», но и заодно заработать деньги на стороне. Результат — выход нового игрока на рынок поставщиков услуг. Но это скорее всего временное явление. Рост стоимости собственной рабочей силы расставит все по местам — вернет компанию в лоно разнообразных внешних «solution-центров», и каждый займется своим делом.
В общем, идеал недостижим. Либо компания много и постоянно платит внешним консультантам и разработчикам, рискуя при этом потерять не только деньги, но и оперативность изменений (вас будут ставить в очередь для ожидания специалистов, а каждый новый специалист долго будет «въезжать» в ваши проблемы). Либо она постоянно платит своим специалистам и время от времени решает проблемы, связанные со сменой версий. И все это в условиях нарастающего в ИТ дефицита квалифицированных кадров.
Прикладные конструкторы
Однако потребность в постоянном развитии бизнес-процессов объективна и для многих предприятий весьма ощутима. Поэтому скорее всего эта объективная потребность вкупе с общей тенденцией к совершенствованию прикладных программных продуктов приведут в конце концов к тому, что постоянное развитие систем будет производиться именно у заказчика — путём их настройки силами собственных специалистов, не являющихся «высокими профессионалами» в разработке действительно нового программного обеспечения. Такое развитие должно идти на основе платформы — богатого и гибкого прикладного конструктора — с помощью самых высокоуровневых инструментов высокоуровневого «пользовательского» программирования, которое будет превращаться в макетирование экранов, записей и отчетов, в составление маршрутов движения документов и в другие подобные работы, во многом относящиеся к уровню специализированных настроек. И именно в этом направлении сейчас развиваются практически все прикладные системы.
О выборе прикладного ПО
Итак, обсудив проблемы развития прикладной системы, вернемся к вопросам ее выбора. В свете нашего обсуждения при выборе прикладного ПО нужно прежде всего оценить «себя», свой бизнес с точки зрения изменчивости бизнес-процессов. И понять, насколько потенциальный продукт хорош для дальнейшего развития и какими способами его можно дальше развивать. Для бизнеса с малой изменчивостью бизнес-процессов во времени (например, стабильное и консервативное крупносерийное производство, классическая банковская деятельность, стабильный сырьевой бизнес) лучшим вариантом может стать максимально готовая система с минимальными возможностями доработок. Если они не нужны — незачем за них платить. Хотя сейчас и в тех отраслях, где бизнес-процессы были очень консервативны, тоже начинают происходить постоянные изменения. Скажем, в банках то и дело разрабатываются новые «банковские продукты», вводится телебанкинг и т. п.
Для динамично меняющихся видов бизнеса и холдинговых структур больше подходят системы высокой степени готовности, но при необходимости способные существенно модифицироваться, например, продукты Microsoft. И хотя общая тенденция к универсализму постепенно сглаживает различия между категориями продуктов, пока еще степень различия довольно велика.
Если бизнесу компании свойственно и то и другое, ей нужны разные продукты, так как любые универсальные средства либо чересчур дороги, либо слишком плохи. Если бизнес включает в себя разные направления, то в такой структуре понадобится несколько программных продуктов. И это — не «зоопарк» ПО, а объективная реальность, необходимая как раз для того, чтобы не тратить лишние деньги.
И последний аспект: при выборе программных продуктов имеет смысл обращать внимание на количество информационных взаимосвязей на своем предприятии, особенно на нижнем уровне. Если компания представляет собой объединение разных бизнесов «под одной крышей» в отсутствие информационных связей между ними на нижнем уровне и от состояния дел в одном бизнесе другой практически не зависит, то для управления таким бизнесом на верхнем уровне можно использовать более простые и легкие системы.
