Нужен совет по организации процесса

[kgenius]

Добрый вечер!
Пишу возможно не совсем по профильной теме, но более подходящей ветки не нашел.
Сейчас столкнулся с одной проблемой и нужен совет. У нас в департаменте ИТ есть департамент бизнес-анализа, в котором я сейчас собственно говоря и работаю. У нас 2 основные задачи:
1) От бизнес-заказчиков через нас проходят ТЗ на разработчиков и обратно от разработчиков к бизнесу возвращается результат.
2) Описываются текущие процессы компании, которые требуют описания. Процессы описываются в разных нотациях, т.к. унифицировать все в одной нотации пока не получилось. Так же пока нет единой нумерации для процессов.
Сейчас есть следующая процессная проблема. Суть в том, что не до конца понятно, как связать процесс внесения изменений в информационные системы с обновлением (поддержанием актуальности) описания бизнес-процессов.
Какие есть проблемы:
1) Может быть связь один ко многим, т.е. одно изменение может потребовать изменения документации по ряду бизнес-процессов.
2) Разработчики сами никак не могут выстроить связь между их изменениями и описаниями БП,
3) До фактических изменений, несмотря на формализацию ТЗ. нельзя точно сказать, в какие описания БП потребуется вносить изменения, т.к. все зависит от конкретной реализации в системе разработчиком.
Вариант, который напрашивается - после внесения изменений разработчиками, внести обязательную стадию внесения изменений в описание БП аналитиком. Но тут возникнут очень большие издержки, на анализ всех существующих БП. Возможно, что нужно, как-то увязать описания БП с областями информационных систем.
Короче, красивого решения пока нет.
Буду рад любым комментариям: личный опыт, лучшие практики, ссылки на литературу и т.д.
Всем спасибо.

Удален за нарушение правил форума при регистрации
администратор

[Александр Алехин]

ссылки на литературу

учебник русского языка.

проходят ТЗ на разработчиков и обратно

ничё не понятно. Дальше читать нет сил и возможности

[Сергей Трофимов]

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

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

[Михаил Шустер]

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

[Михаил Шустер]

учебник русского языка

Это фол

[Щербинин Кирилл]

Это автор первого поста. Видимо нужно все-таки иногда читать правила, при регистрации. Не уверен, что все правильно сделал и что не получу бан в течении следующих 30 минут.

[Щербинин Кирилл]

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

Сергей, спасибо за ответ. А можете пару примеров привести!? Рад был бы посмотреть.

[Щербинин Кирилл]

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

К сожалению мне и самому все не до конца понятно. Постараюсь расписать более подробно текущий процесс, в ближайшие дни.

[Щербинин Кирилл]

Итак, постараюсь описать более подробно возникшую ситуацию.
Существует департамент ИТ, в который входят подразделение бизнес-анализа и подразделение разработки. Входят и другие подразделения, типа сопровождения и системного администрирования, но они в настоящий момент не представляют интереса. С другой стороны есть бизнес-заказчики. Департамент бизнес-анализа сравнительно недавно появился в рамках департамента ИТ (чуть более года). До этого разработчики были бизнес-аналитиками, в какой-то степени. Несмотря на год работы, пока не получается полностью выстроить процесс, связанный с описанием текущих процессов и документированием изменений.
В настоящий момент есть два основных процесса, которыми занимается подразделение бизнес-анализа: участие в изменениях и документирование бизнес-процессов компании. Опишу их подробнее.
Как выглядит процесс изменений в настоящий момент:
1) От бизнес-заказчиков поступает задание на автоматизацию. Обычно оно поступает в виде ТЗ, по утвержденному шаблону. Далее оно диспечеризируется на подразделение бизнес-анализа.
2) На стадии бизнес-анализа оценивается, что хочет заказчик (техническая осуществимость, непротиворечивость, риски и т.д.), вносятся необходимые правки и далее ТЗ передается в разработку.
3) На стадии разработки происходит системный анализ и утверждение, если требуется, с бизнес-анализом (например, финальное решение будет несколько отличаться от согласованного с заказчиком). Далее идет уже сама разработка.
4) После этого готовое решение передается в бизнес-анализ. На тестовой БД идет презентация и тестирования для заказчика. Если все ok, то дается сигнал разработчику.
5) Разработчик сообщает о готовности подразделению сопровождения (они занимаются тиражированием новой функциональности).
6) Изменения попадают в продуктив. Релизы происходят один раз в неделю.
Работы по изменениям (т.е. работа подразделений бизнес-анализа и разработки) происходят в Microsoft Project.
Про процесс документирования бизнес-процессов писать особо нечего, т.к. это в большей степени неформализованный процесс. Описываются текущие процессы компании: часть процессов просто не описано, часть процессов требуют актуализации. Процессы описываются в разных нотациях (IDEF, EPC, произвольный формат в Visio, просто текстом), т.к. унифицировать все в одной нотации пока не получилось. Так же пока нет единой нумерации для процессов, чтобы можно было давать ссылку на процесс.
Какие сейчас есть проблемы:
1) Непонятно, как связать процесс внесения изменений в информационные системы с обновлением (поддержанием актуальности) описания бизнес-процессов. В первом своем посту я не упомянул еще о том, что есть часть изменений, которые проходят мимо подразделения бизнес-анализа. А именно:
a) Исправление багов. Напрямую решают разработчики. По идее, исправление багов никак не должно затронуть бизнес-логику. Но ключевое слово тут "по идее". И в отличии от изменений, исправление багов происходит не в Project, а в системе HelpDesk. Увидеть, что происходит в HelpDesk проблематично.
b) Часть подразделений (Финансы, Управление по качеству) имеют право подавать ТЗ напрямую в разработку, минуя бизнес-анализ. Такое право получили, т.к. с одной стороны пишут сразу правильные ТЗ, а с другой стороны, чтобы сократить время на анализ, т.к. часто оперируют специфическими процессами своего подразделения. Тут так получилось исторически, что в разработке есть предметные специалисты, которые могут понять бизнес-заказчиков намного быстрее, чем в варианте с подключением бизнес-аналитиков.
c) Сам департамент ИТ может написать заявку на изменения. Как бы внутренние изменения. Обычно они не затрагивают бизнес-логику, а только привносят что-то технологичное, но см. пункт a.
Наверное, нужно все изменения заворачивать на бизнес-анализ!? Как минимум о них нужно знать пост-фактум.
Но это только одна часть данного вопроса. Вторая часть заключается в связи между изменением и описанием БП. Непонятно, как увязать изменения с необходимостью внесения правок в описание БП.
Какие тут есть затруднения:
a) Одно изменение может требовать обновления описаний нескольких БП. Как построить такую связь?
b) Разработчики сами никак не могут выстроить связь между их изменениями и описаниями БП.
c) До фактических изменений, несмотря на формализацию ТЗ, нельзя точно сказать, в какие описания БП потребуется вносить изменения, т.к. все зависит от конкретной реализации в системе разработчиком.
Вариант, который напрашивается - после внесения изменений разработчиками, внести обязательную стадию внесения изменений в описание БП аналитиком. Но тут возникнут очень большие издержки, на анализ всех существующих БП, т.к. нет связи между информационной системой и описаниями бизнес-процессов.
Отдельным вопросом тут встает стадия, на которой нужно вносить изменения в описания БП. По идее нужно делать до тиражирования самих изменений в продуктив. Но специфика бизнеса (продуктовый ритейл) требует наискорейших изменений. А если менять описания БП пост-фактум, то непонятно насколько может растянуться процесс. Тут я говорю именно про изменения описаний БП. Всякие там инструкции и регламенты правят обычно до внесения изменений в продуктив.
2) Непонятно, в каком формате (нотации, информационной системе) требуется поддерживать описание БП, чтобы можно было всегда увязать изменения с необходимостью анализа описания БП.

Коллеги, описал, как смог. Больше пока мыслей нет.
Заранее спасибо за помощь.

[Роман Озеранский]

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

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

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

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

А эти два вида деятельности почему определены именно как процессы?

т.к. часто оперируют специфическими процессами своего подразделения.

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

[Михаил Шустер]

Щербинин Кирилл
Я постараюсь что-нибудь сказать, подумав
Сходу-а чем по большому счету не устраивает ситуация? Описание отстает от продукта-по моему это всегда так, у одних больше, у других меньше. Есть жалобы, потери времени, денег? Или просто как в анекдоте "неаккуратно как-то"?

[Сергей Киселёв]

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

[Щербинин Кирилл]

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

Готов принять альтернативную версию глоссария.

[Щербинин Кирилл]

Щербинин Кирилл
Я постараюсь что-нибудь сказать, подумав
Сходу-а чем по большому счету не устраивает ситуация? Описание отстает от продукта-по моему это всегда так, у одних больше, у других меньше. Есть жалобы, потери времени, денег? Или просто как в анекдоте "неаккуратно как-то"?

Самая большая проблема в том, что нет понимания, как правильно организовать гарантированное документирование изменений по БП. Как и писал, часть изменений вообще минует контур нашего подразделения. А то, что проходит через нас нужно постоянно анализировать, на предмет того, в какие БП требуется вносить изменения. В настоящий момент описание БП привязано к укрупненным сущностям (Товар, Поставщики, и т.д.), но какая-нибудь автоматизация может затронуть сразу несколько бизнес-областей и потребуется просматривать все БП, чтобы понять, куда вносить изменения. Может быть конечно так и должно быть, но что-то мне подсказывает, что нужно что-то изменить.

[Щербинин Кирилл]

Кратко - за тз отвечает заказчик. Бизнес-анализ может привлекаться к разработке тз в качестве "внешнего" для заказчика ресурса и должен согласовывать все тз на предмет соответствия нормативной базе.

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

[Михаил Шустер]

столкнулись с проблемой поддержки актуальности данных описаний

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

Кирилл, я спросил ЗАЧЕМ вам надо иметь актуальные описания БП. Какая польза от актуальных и какой вред от их отсутствия
Это серьезный, важный вопрос, от которого зависит все остальное
Еще важный вопрос - есть у вас подразделение, которое отвечает за наладку организации управления? Служба качества, стандартизации, директор по развитию или кто еще. На заре автоматизации, таки да, это пытались всунуть в ответственность IT-службы но это повально позади

[Щербинин Кирилл]

столкнулись с проблемой поддержки актуальности данных описаний

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

Кирилл, я спросил ЗАЧЕМ вам надо иметь актуальные описания БП. Какая польза от актуальных и какой вред от их отсутствия
Это серьезный, важный вопрос, от которого зависит все остальное
Еще важный вопрос - есть у вас подразделение, которое отвечает за наладку организации управления? Служба качества, стандартизации, директор по развитию или кто еще. На заре автоматизации, таки да, это пытались всунуть в ответственность IT-службы но это повально позади

Михаил, актуальные описания БП нужны, т.к. с ростом компании и усложнением БП наметилась тенденция к утрате знаний об этих самых процессах. Даже сами владельцы процессов порой не уверены, как функционирует тот или иной процесс. Наше подразделение описывает БП на уровне информационных систем. Описание и поддержание актуальности - одна из функций нашего подразделения.
По поводу второго вопроса. У нас есть служба качества, но в ее задачи входит поддержка физических (не ИТ) процессов компании: регламенты и инструкции для магазинов, прохождение ISO и т.д. Т.е. по сути произошло разделение зоны ответственности за описание и поддержку процессов, между ИТ и не ИТ.

[Михаил Шустер]

Щербинин Кирилл
Правило гласит: задайте 5 раз вопрос "почему". На первый вы ответили, осталось 4
Мне ваша ситуация понятна, есть туча опыта по теме. Но я не стану отвечать на незаданные вопросы, это методически неправильно. Ответы вы находите сами, я могу лишь подтолкнуть-направить

[Щербинин Кирилл]

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

[Сергей Прохоров]

По поводу второго вопроса. У нас есть служба качества, но в ее задачи входит поддержка физических (не ИТ) процессов компании: регламенты и инструкции для магазинов, прохождение ISO и т.д. Т.е. по сути произошло разделение зоны ответственности за описание и поддержку процессов, между ИТ и не ИТ.

Т.е. получилось, что основной БП "ушел в свободное плавание". Так?