Опыт применения системной инженерии при внедрении 1С:ERP

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

 

 

Меня зовут Сергей Привалов, я руководитель проектов в компании «Первый БИТ».

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

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

 

Практика применения TOGAF и нотации ArchiMate при внедрении 1С:ERP

 

Во вложении к публикации я добавил архив, куда входит:

• Шаблон примера, реализованный в нотации Archimate – именно его мы сейчас и будем рассматривать.

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

Для работы с этими файлами понадобится инструмент Archi – его можно скачать по ссылке https://www.archimatetool.com/download/

 

 

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

Наша практика такова, что «пришивать пуговицы» мы умеем очень хорошо. У нас есть техническое задание и высококвалифицированные программисты – пришить пуговицу большого труда не составляет. Но возникает вопрос: «Кто сшил костюм?»

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

• Жизненного цикла продукта – в нашем случае, ERP-системы – от момента возникновения идеи до вывода продукта из эксплуатации.

• Жизненного цикла управления проектом, в рамках которого происходит разработка продукта.

Причем вне зависимости от используемых в процессе внедрения стандартов (ГОСТ 34 или на PMBoK), и модели этапности (через фазы, стадии или этапы), в жизненном цикле проекта всегда есть две ключевые контрольные точки: валидация и верификация.

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

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

 

 

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

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

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

 

 

Системное мышление рассматривает все, что нас окружает, как единую совокупность взаимосвязанных элементов или как систему систем, оперируя при этом такими понятиями как холархия (holarchy) и холоны (holon).

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

Независимо от того, что именно мы рассматриваем, выделяются три типа систем:

• Обеспечивающая – та, которая создает целевую систему;

• Целевая – та, которая разрабатывается;

• Использующая – та, которая будет с этой системой взаимодействовать и получать результат.

Важно научиться применять этот способ мышления – рассматривать любое явление как систему систем.

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

Когда мы на эту сложную систему пытаемся как на глобус натянуть еще одну сложную систему – ERP, возникают сложности, потому что эти две системы систем наслаиваются друг на друга

Как применить системное мышление на практике, чтобы оно действительно приносило пользу?

 

 

На слайде показан один из примеров модели жизненного цикла проекта – здесь в нотации Archimate представлены взаимосвязи объектов, которые мы рассматриваем как системы.

 

 

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

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

Почему мы используем термин «услуга»? Потому что понятия «организационная ценность» или «полезность» – достаточно сложные для восприятия, и требуют глубокого погружения в предметную область. А понятие «услуга» – привычное. На нем удобно выстраивать коммуникации – как внутри команды, так и с заказчиком.

Мы ежедневно сталкиваемся с услугами: люди оказывают их друг другу, системы – людям, и даже системы – другим системам. Фактически, услуга – это синхронизатор смыслов, вокруг которого строятся все взаимодействия в системе.

 

 

На схеме представлена принципиальная схема того, как услуга «рождается». Она может появиться:

• Из технологичной или предметной плоскости.

• Либо из Бизнес-процессов – там, где есть Практика и сами Бизнес-процессы. Практику можно представить как верхнеуровневый или функциональный бизнес-процесс, а сами бизнес-процессы – это некоторый поток работы.

Итого, вся наша работа по внедрению может быть интерпретирована:

• как в реализацию сервиса для прикладного решения;

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

 

 

Ключевая сложность – выделить эту услугу и сформулировать ее так, чтобы она действительно отражала задачу, которую мы хотим решить. На первый взгляд, все просто: есть боль –> есть решение (услуга) –> есть способ поставки этой услуги.

Но для того, чтобы услуга действительно работала, необходимо выстроить вокруг нее взаимосвязь объектов, влияющих:

• на формулировку самой услуги;

• на критерии, по которым мы в дальнейшем будем ее рассматривать на стадиях «Программа и методика испытаний», «Валидация системы в работе».

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

Давайте разберем смысловые нагрузки на эти специфические обозначения.

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

Второе – Боль (или Драйвер в нотации Archimate). Это некоторая обеспокоенность, которая вынуждает нас задуматься о том, что нам нужна эта Услуга.

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

Допустим, если мы хотим пойти в ближайший магазин там что-то купить, то:

• наша первичная Боль – поесть;

• Услуга – покупка еды;

• и у нас есть требование – еда должна быть свежая, а магазин должен быть рядом.

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

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

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

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

 

 

Здесь показана принципиальная схема той цепочки, которая как методика заложена в нотацию Archimate (разработана компанией Open Group в рамках методологии TOGAF). Она отражает:

• ADM – тот путь, по которому мы должны идти, применяя эту методику;

• само представление архитектуры, которое разделяется на:

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

  • слой приложений – целый комплекс взаимосвязанных ИТ-систем (ERP, Документооборот, все что угодно);

  • технологический слой, железо – то самое жизненное пространство, которое обеспечивает работу программы.

Обратите внимание, что между услугами (сервисами) нет ничего, кроме стрелок. Это самое ключевое, про что не всегда рассказывают, пытаясь применить на практике подход TOGAF. Увлекаются именно описательными частями взаимосвязей между объектами, но сама суть остается в стороне. А именно это – самое главное

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

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

 

 

Расскажу небольшую сказку, которую я эксплуатирую уже 6 лет. Она отлично иллюстрирует два основных подхода к внедрению систем – неважно, идет ли речь об 1С или о чем-то другом.

 

 

Жила-была молодая, красивая, задорная прачка. Она стирала белье, и это ей нравилось.

Это был ее источник дохода, и клиенты были довольны.

 

 

Шло время, прачка постарела, и ее доска для стирки подыстерлась.

Услышала она, что где-то в тридевятом царстве, в тридесятом государстве есть компания «Молодильные яблоки» – делают все, что только не попросишь.

И решила прачка обратиться к ним, заказать себе новую доску.

 

 

Приехала делегация из компании «Молодильные яблоки» – умные красивые ребята в галстуках с красивыми графиками.

Со всех сторон ее окружили и давай пытать: «Расскажи, сколько белья ты стираешь? С какой частотой двигаешь его по этой доске? В какой позе стоишь?»

Прачка растерялась, но ответила как могла – раз уж позвала, надо ждать какой-то результат.

 

 

Пока идет работа, решила подтянуть теорию своего бизнеса – сидит, читает книги о своей доске.

 

 

Прошло время, приходят ребята из «Молодильных яблок» и говорят: «Все готово, принимай работу!» И вместо доски вручают ей стиральную машину.

Делать нечего – надо изучать и пробовать применить.

 

 

Начинает прачка смотреть, как это все включается-выключается, пихать в машину белье, которое она раньше стирала, и проверять ее на возможность впихнуть невпихуемое…

Все попробовала, все работает!

Бабка даже помолодела от радости – сама стала молодой, задорной, как и раньше.

 

 

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

 

 

Вот и сказке конец. А кто слушал – молодец.

Есть два пути, по которым идет внедрение.

• Первый – неправильный, но часто встречающийся. Заказчик говорит: «У меня в УПП было так, сделай мне то же самое в ERP». Он неумолим и настаивает на своем. В результате зачастую исполнитель соглашается и начинает через колено ломать эту ERP, пытаясь там воспроизвести все то, как было в УПП. Но поскольку архитектуры у двух систем разные, то в конечном итоге обновлять доработки становится сложно или невозможно. В результате развития не происходит. Мы просто стоим на месте – взяли и поменяли одно хорошее на другое такое же хорошее. Но лучшего мы не нашли. Бывает, конечно, что лучшее – враг хорошего, но в данном случае технологическое развитие всегда идет на пользу.

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

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

 

 

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

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

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

 

 

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

Покажу небольшой пример.

 

 

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

Определение организационной структуры предприятия позволит в будущем понимать сквозные связи всех сущностей описания в нотации ArchiMate:

• что и для кого мы делаем;

• кто является владельцем того или иного процесса;

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

 

 

Следующий важный шаг – описание бизнес процессов.

 

 

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

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

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

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

Следующим шагом я предлагаю им представить каждое подразделение как самостоятельную организацию. Например, отдел продаж – это не отдел продаж компании «Рога и копыта», а ООО «Отдел продаж». И все сотрудники отдела продаж должны сформулировать:

• За что компания платит им деньги?

• Какую пользу они приносят в компании?

• Чем они отличаются от аутсорсинга, который мог бы оказывать ту же услугу более качественно?

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

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

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

• какие услуги отдел ожидает получить от других подразделений (входящие потоки)

• какие услуги отдел готов предоставлять сам (исходящие потоки).

После чего происходит синхронизация входящих и исходящих потоков каждого отдела. Допустим, выход с отдела закупок является входом для отдела продаж.

А самое главное, мы получаем четкое понимание бизнес-слоя – как внутри компании, так и в отношении к ИТ-системам.

Если же мы применяем такой подход к программному уровню приложения 1С:ERP, то у нас такие же требования, ожидания и потребности в услугах к самой системе, которая автоматизирует нашу деятельность.

 

 

Покажу, как выглядит сквозной пример описания проекта, Archimate-схема которого приложена к публикации. Корневое представление находится в ветке View и называется «Сводная проекта».

 

 

Первым делом рассмотрим организационную структуру – всегда с этого начинается.

Здесь мы можем сформировать некое представление, которое можно масштабировать до любого уровня. Например, мы можем раскрыть представление «Отдел расчетов as is» – провалиться внутрь и посмотреть его структуру подробнее.

 

 

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

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

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

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

 

 

Следующим шагом нужно оформить бизнес-процесс. Открываем ветку View – Бизнес-процессы – Бизнес-процессы as is.

Обратите внимание, что мы раскладываем бизнес-процессы по классическим слоям:

• Процессы управления

• Основные процессы

• Обеспечивающие процессы

Раскроем представление «Продажи as is».

 

 

Допустим, у нас при внедрении 1С:ERP в основном бизнес-процессе «Продажи» требуется что-то рассчитать – условно, автоматизировать функцию «Складывание x+y». С помощью этого представления у нас описано, как это сейчас организовано в системе as is.

 

 

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

Задача менеджера, который с этим работает – выдать клиенту результат расчета. В частности, это может быть калькулятор маржинальности.

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

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

• Расчетчик тоже считает не в уме, а в Excel. Т.е. исполнителем услуги, по сути, является Excel.

• В дальнейшем расчетчик эту услугу транслирует менеджеру.

• Менеджер получает эту услугу от расчетчика.

• И дальше выдает ее заказчику.

• После чего процесс завершается.

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

Поэтому следующим шагом мы начинаем думать, что с этим делать.

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

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

 

 

Чтобы пройти эту цепочку, предлагаю рассмотреть схемы по доработке – они находятся в ветке View – Продукты – Доработка x+y.

 

 

Сначала мы по результатам обсуждения фиксируем реестр услуг от каждого подразделения – кто что ждет, кто что хочет. Это зафиксировано на представлении «Business Model Canvas».

 

 

На представлении «ФР 001 Сложение x+y» зафиксировано, как этот бизнес-процесс был организован в самом начале.

 

 

На представлении «ФР 001 Сложение x+y в.1» зафиксировано промежуточное состояние того, каким мы хотим видеть бизнес-процесс. В частности, мы хотим заменить людей, и это рождает функциональный разрыв, потому что в типовой 1С:ERP нет функциональности, которая нужна заказчику.

 

 

Если посмотреть на то, что показывает визуализатор, для решения этой задачи есть:

• «Услуга расчета x+y as is» – то, что мы сейчас используем;

• «Услуга расчета x+y to be» – наше будущее, автоматизация;

• «Клиент» – мы понимаем, для кого важна эта услуга;

• «Z получен» – окончание события;

• «Запросить результат x+y» – то, откуда вообще вся эта история родилась.

Таким образом, мы можем видеть связи: откуда родилась эта потребность, как выглядела услуга раньше, и какой она будет сейчас – что будет, если мы заменим одну услугу другой. Все понятно, просто и вполне доступно.

Итого: у нас есть функциональный разрыв, который будет замещен компонентом «Доработка ФР 001».

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

 

 

В результате мы видим вполне простую историю, в которой есть:

• начальное состояние ai is – ФР 001 Сложение x+y;

• промежуточное состояние – ФР 001 Сложение x+y в.1

• и конечное состояние, где доработки уже интегрированы в продукт – ФР 001 Сложение x+y в.2

Преимущества такого описания:

• Это удобно для тех, кто непосредственно и предметно решает эту задачу – программисты, аналитики и прочее.

• Для заказчика очевидна хронология событий и преемственность – от того, как было, к тому, к чему мы пришли. Он может сказать: «Да, я действительно помню, что мы это делали. Это полезно».

• Мы охватили этап планирования, моделирования и оформления, приведя все это к конечной услуге.

 

 

Далее начинается этап реализации, на котором мы регулярно проводим регулярные статус-встречи.

Покажу, как упростить проведение этих статус-встреч с помощью Archimate – выстроить их так, чтобы они были эффективными и полезными.

Мы используем компактную визуальную структуру проекта, где весь пакет работ представлен на одном листе – пример вы можете посмотреть в ветке View – Работы – КПГ.

 

 

Открыв визуализатор, мы можем проанализировать конкретную задачу:

• для чего мы ее делаем – чтобы закрыть функциональный разрыв «ФР 001»;

• как мы это делаем – покрываем его «Доработкой ФР 001».

Отсюда мы можем «провалиться» дальше и посмотреть, что делает эта доработка – откуда возникла потребность и как она связана с другими элементами системы. Это первая полезность.

 

 

Вторая полезность связана с тем, что вся информация по статус-встрече должна помещаться на одном листе и содержать четыре основных раздела:

• Описание этапа проекта

• Риски этапа проекта

• Бюджет этапа проекта

• Реестр пакетов работ – представление набора пакетов работ на конкретную дату. Те, что слева от контрольной точки – должны быть выполнены, те, что справа – предстоящие.

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

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

Кроме этого, Archimate позволяет организовать совместный доступ через GIT – эта возможность предусмотрена в бесплатном программном продукте Archi.

 

 

Хочу зафиксировать еще раз:

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

• Фокус внимания – услуга. Любая наша работа должна рассматриваться через призму того, что мы формируем услугу для кого-то. Если заказчик идеологически согласится, что реализованные нами доработки оказывают нужную ему услугу, мы повысим вероятность успеха проекта.

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

• Две контрольные точки, про которые нужно помнить в самом начале проекта – это верификация и валидация.
  Верификация – это проверка соответствия результата техническому заданию. Если в ТЗ написано, что кнопка круглая, она должна быть круглой. Это несложно проверить, и мы это умеем.
  Валидация – намного сложнее. Это проверка соответствия результата ожиданиям заказчика. Она зависит не только от формальных требований, но и от восприятия, готовности пользователей и согласованности внутренних процессов. Но если мы сделаем реестр и карты услуг и будем в течение проекта их регулярно обсуждать, это значительно снизит вероятность проблем на этапе валидации. В результате решается основная проблема проекта, возникающая на контрольной точке валидации:

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

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.