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

Место диагностики при внедрении автоматизированной системы

Что значит «успешное внедрение»

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

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

Диагностики нельзя избежать

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

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

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

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

Как следствие система, фактически, не будет запущена. В борьбе между проектными решениями и «логикой вещей» всегда победит «логика вещей».

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

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

Согласовывайте полный набор требований к системе до начала разработки и внедрения.

Диагностика требует учёта интересов разных заинтересованных лиц

Результатом диагностики является техническое задание. Этот документ служит сразу нескольким целям и используется разными лицами на проекте.

Разработчик

Одним из ключевых потребителей технического задания является разработчик. Он должен увидеть в этом задании, ответ на вопрос «Что нужно сделать?». Техническое задание должно включать описание прикладного решения на понятном разработчику языке, но не должно ограничивать свободу разработчика при выборе способов реализации требований.

Избегайте включения в техническое задание способов реализации требований. Оставляйте выбор способов реализации разработчику.

Заказчик

Не менее важным, чем разработчик, заинтересованным лицом в отношении технического задания является заказчик. Он ожидает увидеть в техническом задании ответ на вопрос «Как будет работать предприятие после запуска системы?». Заказчик должен узнать в этом техническом задании своё предприятие вплоть до конкретных работников. Только тогда он будет уверен, что система заработает. Для этой цели в техническое задание следует включить описание работы предприятия после запуска системы на понятном заказчику языке. Не забывайте, что наиболее понятным руководству предприятия языком является язык приказов и регламентов, т.е. текст.

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

Не злоупотребляйте графическими нотациями. Текст обладает непревзойдёнными выразительными возможностями для описания сложной бизнес-логики.

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

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

Аналитик

Не нужно забывать, что сам аналитик является важным потребителем технического задания. Ведь в задачу аналитика входит сдача системы заказчику. Сдача системы заказчику выполняется путём сравнения фактических характеристик системы с требованиями к ней. Таким образом, техническое задание должно содержать ответ на вопрос «Как заказчик будет принимать систему?». Для ответа на этот вопрос используется согласованная с заказчиком программа и методика испытаний. Чаще всего этот документ содержит описание контрольного примера и процедуры проведения испытаний. Релиз системы, прошедший приёмку по программе и методике испытаний на контрольном примере, допускается к опытной эксплуатации. Фактически, программа и методика испытаний на контрольном примере венчает процесс проработки требований к прикладному решению. Пока описание испытаний прикладного решения не согласовано с заказчиком, аналитик не может считать процесс согласования требований завершённым.

Не следует откладывать подготовку и согласование программы и методики испытаний. Наилучшей практикой является включение программы и методики испытаний непосредственно в техническое задание.

Перед началом диагностики должно быть чётко определены назначение системы и цели её создания

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

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

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

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

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

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

Множество проблем на проектах проистекают от того, что требования к системе выдают одни люди, а принимают систему — совсем другие.

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

Содержание диагностики

Ключ к успешному внедрению автоматизированной системы — корректная реализация модели управления и учёта предприятия в прикладном программном обеспечении системы.

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

Проработка системно независимой информационной модели предприятия

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

Понимание логики работы предприятия обязательно требует рассмотрения:

• -  управленческих решений, принимаемых руководством всех уровней;
• -  используемых при принятии решений показателей и выходных форм;
• -  способов расчёта показателей вплоть до ввода первичных документов;
• -  способов оформления результатов принятых решений и их доставки до исполнителей;
• -  способов контроля исполнения решений и установленных правил.
   

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

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

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

Согласованная информационная модель вместе с проблемами и критериями уже сразу позволяет утвердить способ приёмки системы:

• -  контрольный пример и методику тестирования будущей системы перед запуском;
• -  план проведения опытной эксплуатации, включающий все действия всех лиц, упомянутых в информационной модели;
• -  способ оценки эффективности системы по исходным проблемам и критериям успеха.

Перевод информационной модели на язык системы

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

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

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

Работа с требованиями при запуске системы

Подготовка системы к вводу в эксплуатацию

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

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

Выявленные упущения нужно устранить, не дожидаясь запуска системы в эксплуатацию.

В процессе опытной эксплуатации

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

При проведении опытной эксплуатации требуется контролировать действия пользователей и обеспечивать полноту и корректность исходных данных для расчёта выходных показателей.

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

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

Конечная оценка эффективности не должна оставлять сомнений в фактическом запуске системы в эксплуатацию.

Краткие итоги

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

Фёдор Дунюшкин, ведущий аналитик ГК "БизнесРешение"
www.clientprav.ru

© БизнесРешение ГК, 2017
© Издание 12NEWS (ИП Маринин А.Л.), 2017