Как мы оптимизировали процессы внедрения 1С: проектная методология КРОК

15.05.24

Бизнес-анализ - Внедрение изменений

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

Меня зовут Павел Власов. За моими плечами 20 лет проектного опыта автоматизации процессов на 1С: 9 лет работы в сети франчайзи 1С и 11 лет в КРОК на проектах внедрений 1С федерального масштаба в корпоративном сегменте. Сейчас руковожу группой консультантов по 1С и управляю производственными процессами масштабных проектов по внедрению 1С в роли старшего технического менеджера. 

На проектах внедрения 1С встречаются характерные проблемы, которые мешают добиваться высоких результатов. Вот некоторые из них:

 


 

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

2. Нечеткие зоны ответственности в команде: один человек – и консультант, и программист, и архитектор.

3. Один консультант работает сразу на 2-4 проектах.

4. Команда проекта часто меняется, на разных этапах разные люди.

5. Консультанты выполняют одни и те же виды работ по-разному, каждый как привык.

6. Оценка проекта проводится без участия производственного отдела.

7. «Проектное рабство» — нет четких границ в проекте, договора типовые, ТЗ размытое с неопределенными рамками и границами, а «клиент всегда прав».

8. Сроки не учитываются, главное – взять проект, «а там разберемся».

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

Чтобы сделать проектное производство более эффективным и управляемым, мы сформировали единые проектные подходы в нашей практике 1С. Без них просто не безопасно вести сложные корпоративные проекты.

Кому и зачем нужны единые проектные подходы

У всех, кто работает на корпоративном рынке, есть своя методология внедрения в том или ином виде. У нас – тоже своя. Мы долго выстраивали процессы – КРОК работает с 1С уже более 13 лет. В основу нашего проектного подхода легла методология Oracle AIM. Когда-то консультанты КРОК получили опыт внедрения ERP-систем этого вендора. За 10 лет мы оптимизировали эту методологию под 1С, исключили лишние документы и адаптировали ее под ГОСТ 34-й серии. У нас много заказчиков, которым нужно, чтобы структура документов соответствовала этому стандарту.

 

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

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

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

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

 

От методологии и инструментов — к проектной культуре

 

 

Во главе всего — люди и их проектная культура. Фундаментом выступает используемая методология и технологии под которые заточены инструменты. Тогда проект любого масштаба  и производственные процессы в нем можно сделать управляемыми — настроенными с нуля в «чистом поле» без потери времени на подготовку и отладку производства.

 

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

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

 

Более подробно про это можно прочесть в нашей другой статье: «Управление требованиями и проектирование в СППР с использованием методологии AIM»‎. 

Мы составляем и записываем инструкции в видеоформате через Vanessa Automation, Yandex SpeechKit и 1Script. Благодаря этому мы получили возможность пересобирать их в автоматическом режиме и поддерживать в актуальном состоянии, даже если изменились элементы интерфейса.

Для управления задачами, декомпозиции, планирования, используем Project и Jira. Для нас Jira — это инструмент управления детальными задачами, трекер, для отслеживания статуса задач и фиксации трудозатрат. К Jira можно подключить и заказчика, и нашу команду. Она позволяет оперативно и прозрачно контролировать ход выполнения работ, выявляя отклонения на каждом этапе проекта.

 

Типичная задача в Jira

 

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

 

Структура проектной команды

 

 

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

Основное управление проектом осуществляют два менеджера — технический менеджер и менеджер проекта.

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

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

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

 

 

Технический архитектор 

Функциональный архитектор

Тимлид для группы

До 10 разработчиков

До 10 консультантов разных грейдов 

(от junior до senior)

Зона ответственности

- подготовка технических разделов проектной документации (интеграции, сервера, отказоустойчивость и т.д.);

- валидация функциональных разрывов на непротиворечивость и техническую реализуемость;

- помощь консультантам в выборе варианта реализации требований;

- согласование постановок задач разработчикам / функциональных дизайнов разработки (ФДР)

- оценка доработок;

- управление разработкой по спринтам, контроль сроков и трудозатрат по разработке;

- формирование регламента разработки и контроль его исполнения;

- контроль качества кода: code-review, анализ кода, автотесты;

- интеграционная архитектура;

- сайзинг и требования к железу; 

- нагрузочное тестирование;

- подготовка стенда разработки;

- подготовка обновлений и релизов.

- управление консультантами;

- функциональная архитектура;

- полнота каталога процессов, требований, форм, доработок

- выбор оптимального способа реализации требований / согласование функциональных дизайнов разработки (ФДР)

- функциональное проектирование;

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

- полнота, консистентность системы;

- архитектура взаимодействия со смежными системами;

- полнота тестирования.

Основной фокус

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

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

Цель

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

Заранее выявлены и устранены риски по производительности. 

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

Количество на проекте

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

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


 

 

Консультант 1С в КРОК совмещает роли системного и бизнес-аналитика. Каждый консультант должен разбираться в предметной области, например, уметь общаться с бухгалтерами на одном языке. Это необходимо чтобы моделировать процессы, предлагать оптимальные бизнес-решения. 

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

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

 

Процессный подход в нашей методологии

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

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

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

 

 

Подсистемы, блоки

ОТЗ: Функциональная архитектура

Бизнес-процессы

ОТЗ: Каталог БП

Требования
и функциональные разрывы

ЧТЗ: Модели БП, Альбом форм, Каталог требований

Доработки

ЧТЗ: Список доработок

Сценарии сквозного
кросс-функционального end-to-end тестирования

Программа и методика испытаний

Инструкции пользователей

Инструкция пользователя

 

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

Каталог бизнес-процессов описывает функциональное содержание системы и функциональные границы будущего проекта автоматизации. Структура каталога является основой для последующего проектирования и разработки системы на базе 1С:СППР.

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

В привязке к бизнес-процессам и/или шагам БП регистрируются требования:

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

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

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

 

Подход по этапам работ и отчетным документам

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

Здесь мы определяем функциональные границы проекта: декомпозируем систему на подсистемы, подсистему на блоки, блоки на бизнес-процессы. 

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

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

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

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

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

Ресурсный план позволяет достаточно точно оценить стоимость проекта автоматизации. При оценке мы используем два метода — ресурсный и нормативно позадачный, проверяя сходимость их результатов. 

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

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

 

  1. Моделирование бизнес-процессов

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

  1. Проектирование и разработка 

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

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

  1. ПСИ

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

Проводится кросс-функциональное тестирование — выделяются и проверяются сквозные процессы от начала до конца, например, от заказа товара до его получения. По итогам формируется протокол с замечаниями и сроками их устранения. Также на этапе ПСИ проводится нагрузочное тестирование для выявления и нивелирования рисков низкой производительности до запуска в опытно-промышленную эксплуатацию (ОПЭ).

  1. Подготовка к опытно-промышленной эксплуатации

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

  1. Опытно-промышленная эксплуатация

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

 

Методология на примере

Рассмотрим, как все это работает на практике. Допустим, у нас проект с 9 подсистемами, 278 бизнес-процессами и множеством интеграций. Эта информация собрана на этапе предпроектного обследования.

 

 

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

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

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

 

 

У нас 9 подсистем, значит, нужно 9 отчетных документов. Их разработка и согласование превращается минимум в 18 задач.

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

Понятно, что вносить и администрировать все 2300 задач в Project — очень сложно. Поэтому в Project вносятся задачи по спринтам и подсистемам. В итоге в Project в данном примере получается около 600 задач, связанных с общим статусом работ, а детальные планы формируются либо в Jira, либо в Excel.

 

Заключение

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

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

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

методология управление командой управление проектами проектная культура

См. также

Бухгалтер vs ERP

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Большинство бухгалтеров привыкли вести учет в конфигурации 1С:Бухгалтерия. Но что бывает, если такого бухгалтера перевести с 1С:Бухгалтерии на ERP? Об основных ошибках бухгалтера после перехода и роли аналитика в том, чтобы помочь бухгалтеру преодолеть трудности и изменить привычные паттерны, пойдет речь в статье.

15.05.2024    1776    0    TanyaRi    27    

20

Переход на современные ERP-решения «1С» – дорожная карта, кейсы, рекомендации

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Статья об основных зонах внимания и часто допускаемых ошибках при внедрении современных ERP-систем – «1С:ERP Управление предприятием» и «1С:ERP.Управление холдингом».

27.04.2024    1599    0    user893825    0    

16

Мастерство внедрения 1С: Секреты успеха от опытного фрилансера

Внедрение изменений 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

01.04.2024    738    0    Prepod2003    7    

2

Как реорганизовать работу проектного департамента, чтобы быть №1

Внедрение изменений Бесплатно (free)

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

14.02.2024    740    0    user1270271    2    

7

Проверочные действия перед внедрением казначейства Бит.Финанс

Внедрение изменений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье мы рассмотрим действия для внедрения системы Бит.Финанс и внедрение казначейства в системе конфигурации Бит.Финанс

13.02.2024    490    0    Koder_Line    0    

0

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

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

30.01.2024    7545    0    user1578851    16    

19

Свободное программное обеспечение в крупной компании – миф или реальность? Как мы переводили 2500 пользователей на Linux

Внедрение изменений Бесплатно (free)

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

29.01.2024    2627    0    user1063453    2    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. muskul 15.05.24 10:07 Сейчас в теме
А у кого то есть методики как "перетащить" эдо и егаис в новую чистенькую БД?
3. DDA4746 16.05.24 08:47 Сейчас в теме
(1) Мой вам совет - запишитесь на консультацию (с)
:))
6. Дмитрий74Чел 235 16.05.24 14:33 Сейчас в теме
2. Birby 109 15.05.24 21:15 Сейчас в теме
Шикарный материал! Хочу у вас работать!)
7. Дмитрий74Чел 235 16.05.24 14:34 Сейчас в теме
4. titanium2008 43 16.05.24 09:02 Сейчас в теме
AIM оракла универсален, молодцы что применили его для 1с.
dimaster; +1 Ответить
5. cesar 45 16.05.24 14:05 Сейчас в теме
(2) Спасибо, мы всегда открыты к сотрудничеству
8. imm0rtal 14 18.05.24 06:59 Сейчас в теме
(2) не смешите мои тапки.
Спросите лучше автора, отчего в офисе КРОК так много горящих окон по вечерам.
9. ermilowww 18.05.24 23:38 Сейчас в теме
Отличная статья!
1. Подскажите, на этапе интервьюирования от пользователей Заказчика собираются всё таки требования к системе?
2. Процессный подход вы применятете на дальнейших этапах внедрения проекта и в какой то момент соединяете изначальные требования с автоматизируемыми процессами? Если, да то подскажите в какой момент соединяются требования с процессами
10. cesar 45 20.05.24 09:31 Сейчас в теме
(9)
1. а)Собираются бизнес требования к Системе (это используется в каталоге БП в описании БП) + б)цели/ожидания по каждой подсистеме от ключевых пользователей Заказчика (это отдельный раздел ОТЗ) + в)текущие проблемы автоматизации (это отдельный раздел ОТЗ). Эти верхнеуровневые бизнес-требования (а), которые позволяют сформировать каталог автоматизируемых бизнес-процессов до 4-го уровня (уровень операций) с описанием и дать точную оценку проекта в ОТЗ (ресурнсый план, дорожную карту). Данные требования записываются в описание процесса (раздел 4.2 ОТЗ по ГОСТу с функциональными требованиями представляется в виде каталога автоматизируемых БП по каждой подсистеме). Т.е. даже уже здесь по итогу интервью требования привязаны к процессам, не просто к Подсистеме или Системе в целом. И делается предварительная оценка степени их покрытия типовым функционалом. Но детальный список требований и окончательный реестр доработок рождается только после моделирования и демонстрации каждого процесса в Системе и фиксируются в ЧТЗ на каждую подсистему. Только там можно убедить заказчика использовать ту методику которая заложена в типовом решении или выявить наоборот новые детальные требования.
2. Изначальные требования по результатам моделирования так и остаются в каталоге бизнес-процессов в текстовом описании процесса, но уточняются формулировки и сам состав процессов (обычно что-то укрупняется что-то добавляется и каталог БП после моделирования может уточниться примерно на 10-15%). А детальные требования регистрируются поштучно и тоже привязываются к процессам и даже шагам процесса. Автоматически кодируются и далее классифицируются.
Оставьте свое сообщение