Про GAP-анализ. Мысли из телеги

Я последние несколько лет фактически занимаюсь gap-анализом, хотя формально мы его так не называем. И понял, что моё выступление на AD на основе чужого опыта было, мягко говоря, самоуверенным.

Коротко я бы свой нынешний опыт описал так. Gap–анализ – это выявление расхождений между текущей и желаемой реальностью. Для его проведения нужно три модели:
1) Модель текущей реальности
2) Целевая модель
3) Метамодель для описания изменений.

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

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

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

Первая и вторая модели обычно описываются в виде наборов бизнес-процессов as-is и to-be, потому что процессы – это удобный способ описания и анализа деятельности и выявления расхождений. Уровень детализации при этом зависит от целей анализа. Если нужно внедрять какую-то конкретную систему, то и описание делают, как правило, достаточно детальным.

Таким образом, общая схема описания включает 4 части:
1) метамодель/словарь/глоссарий – какое-то представление вашего способа описания gap-ов/изменений
2) модель as-is
3) модель to-be
4) описание gap-ов/изменений

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

Телега https://t.me/itsysdes/59999