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