Преимущества индивидуального подхода к автоматизации

Исторический обзор

Уже вначале 60-х годов XX века, на заре применения информационных технологий для автоматизации управления и учёта в бизнесе, было замечено, что разные организации для одних и тех же видов деятельности применяют идентичные или схожие модели учёта и управления и требуют от программистов решения одних и тех же задач. В связи с этим в ИТ-среде возник интерес к повторному использованию наработок, полученных при автоматизации управления по заказам организаций.

ИТ-сообществу потребовалось более 30 лет для нахождения приемлемых системно-независимых способов описания бизнес-задач и создания первых промышленных программ с типовыми решениями. С тех пор — 90-х годов XX века — корпоративные прикладные решения стали упаковываться в коробки и продаваться в магазинах, так же как двумя десятилетиями ранее стали продаваться небольшие однопользовательские программные продукты, такие как текстовые редакторы и электронные таблицы.

Пожалуй, самым известным в России готовым решением, охватывающим множество областей учёта и управления, стала немецкая система SAP R/3, появившаяся во второй половине 90-х. В её создании были задействованы десятки тысяч программистов, а общая трудоёмкость разработки измерялась миллионами человеко-дней.

Однако, с появлением корпоративных прикладных систем «в коробке» ожидавшийся золотой век автоматизации не наступил. К концу 90-х годов XX века ярко проявила себя ещё одна тенденция — повсеместный провал корпоративных проектов автоматизации. По оценке авторитетных зарубежных аналитических агентств более 90% проектов создания корпоративных автоматизированных систем не признавались их заказчиками успешными.

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

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

На западе активный поиск решения проблемы срыва проектов автоматизации шёл двумя основными путями:

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

Из первого пути родилась особая дисциплина менеджмента «Управление изменениями». Поиски на втором пути породили многочисленные методики гибкой, итерационной разработки программного обеспечения. Нужно заметить, что по первому пути пошли производители типовых «коробочных решений», а по второму — разработчики решений под заказ.

Параллельно совершенствовались и сами типовые решения. Разработчики коробочных решений снабдили свои программы многочисленными средствами подстройки под особенности того или иного предприятия, что существенно увеличило адаптивность типовых решений. Более того, типовые решения ведущих разработчиков стали открыты для доработок путём расширения или изменения встроенных функций. Изучив специальный язык программирования сотрудник ИТ-службы заказчика или программист со стороны может модифицировать исходное типовое решение.

Таким образом, основные черты лучших мировых практик выполнения проектов автоматизации управления сформировались через одновременное совершенствование в трёх областях:

• менеджмент проектов;
• унифицированные методики создания программного обеспечения;
• инструментарий проектирования, разработки и настройки систем.

Жизненный цикл успешного ИТ-проекта вне зависимости от выбранного прикладного решения проходил фазы бизнес-моделирования, согласования требований к автоматизации, проектирования, разработки, внедрения и завершения.

Отечественные предприятия и ИТ-специалисты не проходили того долгого пути, что и их западные коллеги. В связи с этим в отечественной практике в первом десятилетии XXI века возник довольно своеобразный подход. Для автоматизации управления на крупных предприятиях предпочтение отдавалось популярным готовым комплексным решениям «из коробки». При этом организационными изменениями в большинстве компании мало кто занимался всерьёз. В тот период преобладало мнение, что автоматизация — это частный вопрос ИТ-службы компании, хотя решение о выборе «крутого» комплексного продукта, который обязательно решит все проблемы управления предприятием, зачастую принимались чиновниками из высшего руководства.

Как следствие, в России появился всем хорошо знакомый причудливый образ доработанного прикладного решения. Такое решение появлялось в результате внесения многочисленных изменений в исходный типовой продукт штатными специалистами ИТ-службы организации по требованиям непосредственных пользователей. Естественно, такие изменения обычно не проходили полноценного документирования. Как результат — с определённого момента не оставалось ни людей, ни документов, полностью способных описать все особенности работы и доработки системы.

Итак, первый ответ многих отечественных предприятий на вопрос «купить готовое прикладное решение или создать своё?» звучит так: «сначала купить готовое прикладное решение, а потом создать из него своё».

Сегодня — во втором десятилетии XXI века — отечественные предприятия демонстрируют гораздо большую зрелость в области автоматизации учёта и управления, чем 10 лет назад. Но вопрос о выборе между типовыми и индивидуальными прикладными решениями по-прежнему является актуальным.

Сравнение типовых и индивидуальных решений

Прежде всего, рассмотрим достоинства каждого варианта. Начнём с готовых (типовых) решений.

Типовые решения

Достоинства типовых решений очевидны — это цена и качество.

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

Зачастую к достоинствам типовых решений относят простоту и скорость получения прикладного решения, готового к эксплуатации. Это мнение ошибочно. Как уже отмечалось, современные прикладные решения — это сложные системы, требующие настройки многочисленных параметров при своём внедрении. Выполнение таких настроек требует специальных знаний и навыков, поэтому внедрение типового продукта всё равно требует привлечения специалистов, хорошо знающих продукт и способных наилучшим способом адаптировать его к особенностям предприятия. Но даже после адаптации продукта остаётся необходимость подгонки организационных механизмов предприятия под особенности типового продукта. Всё это приводит к дополнительным затратам времени и средств.

Индивидуальные решения

Достоинства индивидуальных решений так же очевидны. Заказывая индивидуальное решение, предприятие ожидает получить продукт, не требующий дополнительной подгонки, полностью соответствующий особенностям организации, содержащий ровно тот функционал, который требуется заказчику.

Однако, разработка индивидуального решения предъявляет повышенные требования к компетенциям партнёра по внедрению. Далеко не все ИТ-компании обладают компетенциями разработчика, поэтому неверный выбор партнёра может привести к созданию некачественного или даже неработоспособного решения.

Вывод

Мы увидели, что и типовые и индивидуальные решения имеют свои достоинства, которые нельзя сбрасывать со счёта, планируя создание автоматизированной системы на длительный срок. Для выбора между типовым и индивидуальным решением требуется более тщательный анализ.

Оптимальный подход к выбору между типовым и индивидуальным решением

При ближайшем рассмотрении оказывается, что выбор между типовым и индивидуальным решением не так уж и сложен. Источник правильной постановки вопроса и правильного ответа на него находится в области назначения создаваемой автоматизированной системы.

Назначение автоматизированной системы — это вид деятельности, который должен стать объектом автоматизации. Именно характеристики вида деятельности определяют выбор между индивидуальным и типовым решением.

Есть такие виды деятельности, которые по своей природе являются унифицированными. Их особенности определяются вовсе не организационными особенностями конкретного предприятия, а экономической, индустриальной или правовой средой функционирования предприятия. К таким видам деятельности относятся все виды деятельности, выполнение которых регламентируется законодательством и/или общеотраслевыми стандартами: бухгалтерский и налоговый учёт, кадровый учёт и взаимоотношения с персоналом, специализированный учёт в отдельных отраслях торговли и промышленности.

Для унифицированных видов деятельности нужно выбирать унифицированные — типовые — решения, производители которых осуществляют непрерывное сопровождение своих продуктов, своевременно выпуская обновления вслед за изменениями нормативных документов. Любое заказное решение будет заранее в проигрыше по сравнению с хорошо зарекомендовавшим себя решением «из коробки».

Противоположная ситуация наблюдается во внутренних процессах управления, для которых законодателем является сама организация в лице своего руководства. Такие системы должны соответствовать внутренним регламентам организации. В таких ситуациях заказчику в первую очередь следует сконцентрироваться не на поиске того или иного решения, а на поиске партнёра по внедрению, способного качественно усвоить индивидуальные требования организации. Ведь любому выбору прикладного решения, предназначенного для автоматизации внутренних процессов управления, должно предшествовать тщательное формулирование требований со стороны организации. Только после тщательного формулирования требований появляется возможность сравнительного анализа возможностей предлагаемых на рынке решений.

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