Волшебное слово «макет»

Лишь в конце работы мы обычно узнаём, с чего нужно было её начать.

Блез Паскаль.

АСУ. «Как много в этом слове!..». Как много в этом слове надежд, планов, сроков, денег, ожиданий и разочарований. Эти представления по отношению к автоматизированным системам возникают и у тех, кто их придумывает, производит, внедряет, и у тех, кто ими хотел бы пользоваться, облегчая свою производственную судьбу. Особенно яркие впечатления рождаются от АСУП или, как стало уже привычнее, от ERP-систем. Ожиданий и разочарований от АСУП, видимо, поровну, но их больше, чем от прочих автоматизационных сестер: АСУ ТП, АСНИ, САПР и пр.

Разные исследователи оглашают различные сведения об успешности внедрений ERP-систем. На Западе всего лишь половина попыток заканчивается успехом^[1], а остальные относят к явно провальным. И нет никаких оснований считать, что доля успешных внедрений в России отличается от западной в лучшую сторону. Эта не очень достоверная, но печальная статистика широко известна, обсуждение и осмысление этого феномена постоянно идет на Интернет-форумах, в специализированных журналах и монографиях. Причины неудач вскрываются, списки советов и рекомендаций, как избежать провала, непрерывно пополняются, но существенного перераспределения долей не происходит.

Критерии успеха

Безусловно, что под неудачным внедрением или его попыткой все мы понимаем различные вещи, хотя бы потому что взгляд на результат зависит от наблюдателя (заказчик, внедренец, руководитель, рядовой работник). Внедренцы называют неудачей, когда заказчик наотрез отказывается от работы с новой АСУП или, самоиронизируя, когда с заказчика не удалось получить запланированные деньги. От заказчика можно услышать формулу неудачи в виде «отсутствие запланированного результата в запланированные сроки и за договорные деньги». При любом понимании неудачи ни заказчик, ни внедренец не склонны говорить о провале громко: провал для заказчика – потерянные деньги, а для внедренца – потерянная репутация. И то, и другое может иметь серьезные последствия, поэтому о неудачах мы слышим, как правило, лишь в неофициальных разговорах. А официально заказчик и внедренец стараются разойтись по-мирному, не хлопая дверьми и подписывая акты о формальном вводе в эксплуатацию. Так явный провал может превратиться сначала в полунеудачу, а потом и в полуудачу.

Понятие успешной автоматизации тоже весьма расплывчато и, как ни странно, не более определено, чем понятие неудачной. Мерой удачи часто служит степень удовлетворенности заказчика или его заявление вида «теперь мы принимаем решения, опираясь на ERP-систему».

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

На первый взгляд, самой академичной выглядит такая формула успешного внедрения: «система полностью (или на x %) соответствует техническому заданию (или спецификациям^[2], требованиям и т. п.)». Да, если иметь точные, подробные и одинаково понимаемые спецификации, то нетрудно оценить близость готового продукта к заданным условиям. И такие спецификации должны быть. Но существуют ли на самом деле точные, подробные и полные спецификации, одинаково понимаемые внедренцем и заказчиком, до начала работ по внедрению ERP-системы? Как правило, спецификации существуют, но они либо чересчур поверхностны, либо толкуются сторонами по-разному, либо содержат грубые ошибки, либо и то и другое и третье, что встречается ещё чаще.

«Ошибки в спецификации?!» – встрепенется внимательный читатель, – «да такого быть не может!». Может. Потому что речь идет не об арифметических, пунктуационных и прочих фактических ошибках, а о концептуальных ошибках, появившихся из-за недопонимания исходной задачи. Именно этот тип ошибок имел в виду признанный авторитет в области надежности программ Гленфорд Майерс, когда писал, что «подготовка спецификаций – один из основных источников ошибок [при разработке программного обеспечения]. … Причина большинства этих ошибок – неправильное понимание потребностей пользователя»^[3].

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

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

«Сделать хотел грозу …»

Для выяснения особенностей объекта автоматизации, для выявления явных и скрытых целей заказчика и для составления общих спецификаций (технического задания) разработчик выделяет значительные ресурсы. Иначе и быть не может, поскольку полнота сведений об объекте служит фундаментом и для разработки, и для внедрения. По российским стандартам^[4] эта фаза работы состоит из трех стадий: формирование требований к АСУ, разработка концепции, разработка техзадания, – которые называют предпроектным обследованием. По методикам некоторых производителей скелетных ERP-систем эта же фаза работы именуется анализом. Основные исполнители на этой фазе – бизнес-аналитики.

Как проводится предпроектное обследование? В несколько перекрывающихся и повторяющихся этапов, а если упрощенно, – то в четыре этапа:

1)    побеседовать с главными заказчиками, услышать главные и наиважнейшие цели автоматизации;

2)    опросить руководителей среднего чина и рядовых работников, чтобы выяснить детали существующих хозяйственных процессов и пожелания по автоматизации;

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

4)    согласовать техзадание с заказчиком.

На каждом из этапов предпроектного обследования происходит передача и преобразование информации, а следовательно, – свойственные им искажения. Сначала главные заказчики излагают свои цели, но какими бы блистательными лекторами они ни были, аналитики усвоят и поймут заявленные цели несколько по-своему. Затем аналитики получат и интерпретируют информацию от руководителей среднего звена. Естественно, что интерпретация внесет новые искажения. Новая порция информации «вступит в реакцию» с предыдущей порцией, и аналитики получат даже не смесь, а синтезируют совершенно новое понимание целей и задач, которое будет сильно отличаться от представлений заказчиков всех рангов.

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

Искажение постановочной задачи на этапах предпроектного обследования

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

И бизнес-аналитики, и руководители понимают сложности и непреодолимые барьеры общения, понимают, что в разговоре (и во множестве разговоров) невозможно однозначно передать друг другу даже принципиальные установления, касающиеся крупного предприятия и крупной ERP-системы. Поэтому в разговорах остается надежда на важнейший этап внедрения – согласование техзадания, в котором будут, как уверены обе стороны, детально описаны задачи и функции АСУ. И согласование позиций обеих сторон откладывается по взаимному молчаливому договору на конец предпроектного обследования.

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

Первая причина. Техзадание пишется бизнес-аналитиками для разработчиков: системных аналитиков, аналитиков-программистов, программистов, но никак не для менеджеров, бухгалтеров, экономистов и кадровиков. Техзадание пишется на языке автоматизаторов, совершенно непонятном заказчикам, которые знают другое: языки маркетинговых схем, машиностроительных чертежей, технологических карт и бухгалтерских балансов.^[5] Промежуточные языки типа HIPO, IDEF0, UML,  придуманные как раз для общения заказчика и разработчика, слабо помогают взаимопониманию по той же причине: они незнакомы и непривычны заказчику. Спотыкаясь на незнакомых терминах и оборотах, даже добросовестный заказчик захлопнет «иноязычный» документ, не добравшись до последней его корки.

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

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

Тогда его подписывают.

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

Ясное осознание, что спроектирована и внедряется не та АСУ, не с теми функциями и не с теми хозяйственными процессами, приходит только на этапе испытаний, когда пользователи системы, от рядовых до «генералов», увидят систему наяву, а не в спецификациях, написанных аналитиками и программистами и понятных только им. Тогда спроектированную и изготовленную систему начинают переделывать, перепроектировать, перепрограммировать, повторно отлаживать и испытывать. Дай бог попасть в цель со второго раза.

Макет – рецепт от искажений

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

Еще в 1976 году Майерс особо подчеркивал: «Единственно важная причина ошибок в программном обеспечении – неправильный перевод информации (из одного представления в другое)»^[6]. Однако тогда, в 1976 году, Майерс видел только одно средство контроля разработки со стороны пользователя: «крайне важно, чтобы… пользователь просмотрел и одобрил… спецификации»^[7]. Однако, как показал последующий опыт, «просмотреть спецификации» – это крайне необходимо, но слишком мало, чтобы выявить ошибки перевода с языка пользовательских требований на язык архитекторов программных систем.

В 1981, независимо друг от друга, Лаура Черер, системный аналитик, и Джеймс Мартин, известнейший ученый, обладатель Пулицеровской премии, в сентябре 2002 года названный журналом Computerworld одним из четырех самых влиятельных людей в компьютерной индустрии, – оба пришли к общему пониманию: чтобы кардинально сократить количество концептуальных, смысловых ошибок в спецификациях, нужно начинать не с них, а с макетирования программной системы.

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

Партия сторонников макетирования росла, в 1984 году к ней публично присоединился Бернард Боар, эксперт в области информационной стратегии и архитектуры, а в 1986 – Фредерик Брукс, бывший руководитель проекта OS/360 в IBM. В статье «Серебряной пули нет: сущность и акциденция в программной инженерии»^[8] Брукс убедительно утверждал: «Правда заключается в том, что клиенты не знают, чего хотят… Они… никогда не задумывались над задачей настолько детально, как это нужно указать в спецификации… На практике клиенты… не в состоянии указать точные требования к программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют. Поэтому одним из наиболее многообещающих современных направлений в технологии… является разработка… макетов систем как часть итеративного процесса разработки спецификаций… Назначение макета – показать, как воплощается выбранная концептуальная структура, чтобы клиент мог проверить её пригодность к использованию и непротиворечивость».

Одной из ключевых публикаций на эту тему в России стала в 1993 книга Григория Громова «Очерки информационной технологии»^[9]. Громов наглядно, в виде схемы, показал тяжесть ошибок, возникающих на разных стадиях разработки, и назвал «мертвым временем» запаздывание в выявлении ошибок, неизбежное в каскадной схеме проектирования. Он выступил за макет программной системы, «тот самый макет, который веками сопровождал любую сколько-нибудь сложную инженерную разработку, а последние 100 лет не сходит со стола электро- и радиоинженеров.»^[10]. По мнению Громова, макет должен служить не только для однократной демонстрации заказчику, но и для выверки решений, созданных на каждом этапе разработки: «На каждый следующий уровень проекта передаётся как само решение, так и доказывающий его верность, а также иллюстрирующий основные заложенные в решение принципы действующий макет. При этом «мертвое время» существования принципиальной ошибки почти для всех участников проекта практически выравнивается до интервала: от формулировки решения данного этапа задачи до изготовления иллюстрирующего его макета»^[11].

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

Итак, рецепт известен, он – в создании макета. Однако до сих пор методика разработки крупных программных комплексов, основанная на макетировании, не стала преобладающей ни за рубежом, ни в России.

Заглянем в действующий российский государственный стандарт «Автоматизированные системы. Стадии создания»^[12]. Стандарт предусматривает, что перед вводом готовой системы в эксплуатацию может пройти 6 стадий разработки и множество этапов. И на всех этих стадиях: формирование требований, разработка концепции, техническое задание, эскизный проект, технический проект, рабочий проект, – на всех идет разработка только документов. И лишь на последнем этапе в последней стадии начинается разработка и адаптация программ. Макетирование в стандарте, которым руководствуются в России вот уже пятнадцать лет, не предусмотрено.

Похожая картина в параллельном стандарте «Единая система программной документации. Стадии разработки»^[13]. В нем тоже нет ни слова о макетах, и если ему следовать, то пользователь заказанной системы впервые увидит её «лицо» и возможности только по ходу приема в эксплуатацию. Ни о какой «итеративности в разработке спецификаций» на основе макета речь не идет^[14].

Эти умолчания крайне удивительны хотя бы потому, что аналогичный стандарт в машиностроении «Единая система конструкторской документации. Стадии разработки»^[15], принятый в 1968 году, намного раньше программных стандартов и раньше выступлений Мартина и Черер, предусматривает изготовление макетов и опытных образцов на каждой стадии проекта, несмотря на то, что производство машиностроительных образцов в то время считалось столь же ресурсоемким, как и производство программ.

Вспомним, тем не менее, что наш разговор начинался с внедрения ERP-систем, а не с их разработки.

Ситуация с внедрением скелетной ERP-системы на крупном предприятии сродни разработке крупного программного комплекса. В проектах обоих видов основополагающим является техзадание, которое по ряду причин, о которых уже говорилось, не может не содержать в себе грубых смысловых ошибок. Эти смысловые ошибки перекочевывают незамеченными с одного этапа внедрения на следующий и проявляются с большим опозданием, которое Громов образно назвал «мертвым временем». Если придуманную Громовым для разработки программных проектов шкалу «мертвого времени» переложить на временную ось внедрения скелетных ERP-систем, то полученная картинка не порадует.

«Мертвое время» ошибки при внедрении скелетной ERP-системы

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

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

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

Однако отнюдь не во всех зарубежных методиках, которые принадлежат самим разработчикам скелетных ERP-систем, встречается слово «макет». Во многих фирменных методиках по-прежнему видится единственный способ общения заказчика и разработчика – согласование документов: «Задание на проектирование должно разрабатываться на основании исходных данных, в том числе полученных на предшествующих стадиях проекта, отраженных в соответствующей документации, подготовленной и утвержденной в установленном порядке»^[16]. И всё. Снова только документация.

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

Всегда ли нужен макет?

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

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

К сожалению, ни одна из современных технологий не гарантирует от первого промаха.

Проектирование сверху вниз

Под нисходящим проектированием понимают последовательную декомпозицию или информационных потоков^[17], или функций, или объектов. На каждом шаге декомпозиции должен получаться все более насыщенный деталями проект системы. На последнем шаге проект передаётся программистам, которые занимаются структурами данных и логикой программ. Совершенно справедливо считается, что этот метод уменьшает количество ошибок проектирования, но он никак не может повлиять на адекватность исходных требований, которые, собственно говоря, и находятся на вершине декомпозиционной пирамиды. И по-прежнему, если на каждом шаге декомпозиции не предъявлять макет пользователям, то любая непонятность в постановке задачи приведет к неожиданным открытиям при сдаче системы.

Следовательно, метод проектирования сверху вниз не заменяет макетирования, и макет следует изготавливать на каждом шаге декомпозиции.

Макет и демонстрационный пример

Демонстрационный пример нужен, чтобы «показать товар лицом», т. е. продемонстрировать покупателям основные возможности ERP-системы для типового предприятия или типовой ситуации. Часто типовая ситуация тождественна потребностям небольшого и молодого предприятия, и почти никогда типовая ситуация не совпадает с потребностями крупного и давно сложившегося производственного организма.

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

Макет и пилотный проект

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

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

Спиральная модель разработки

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

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

Итог

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

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

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