Учебно-методический комплекс дисциплины Редакция 1
жүктеу/скачать 1,47 Mb.
|
- Бұл бет үшін навигация:
- Транзакция (Transaction)
| Рис. 4.3. Три составляющих Проектирования
Назначением Проектирования является соблюдение тонкого баланса трех составляющих с целью максимального удовлетворения потребностей бизнеса, которые постоянно изменяются. Изменение одной из трех составляющих влияет как минимум еще на одну, а то и на две оставшиеся. Чтобы разрабатывать эффективные решения, поставщикам услуг крайне важно понимать движущие факторы бизнеса и его потребности. Проектирование часто воспринимается только как стадия, предшествующая Эксплуатации. В ITIL подход несколько другой. Проектирование должно не только предложить эффективные решения, но и обеспечить возможность эффективного управления этими решениями в течение всего жизненного цикла. Если объединить всё вышесказанное, то целостный и правильный подход к проектированию должен предусматривать разработку услуг с механизмами и функциями управления и улучшения на всех этапах жизненного цикла. Люди, ответственные за управление Проектированием, должны убедиться в том, что обеспечено следующее: наличие хорошей взаимосвязи между различными действиями в рамках проектирования и другими частями, в том числе планами и стратегиями IT и бизнеса; доступность последних версий планов и стратегий бизнеса для тех, кто участвует в проектировании; соответствие проектной документации планам и стратегиям бизнеса и IT; архитектуры и дизайны: гибки, а, следовательно, способны быстро реагировать на новые потребности бизнеса; интегрированы со всеми стратегиями и политиками бизнеса и IT; поддерживают потребности других стадий жизненного цикла услуги; содействуют продвижению новых или измененных услуг, соответствующих потребностям бизнеса. Одним из подэтапов проектирования является определение и последующее документирование требований бизнеса и его драйверов. Под драйверами здесь понимается некие движущие бизнес-факторы: люди, информация и задачи, которые обеспечивают достижение поставленных целей. Для регулирования процессов проектирования информация делится на две категории: Информация о требованиях к существующим услугам - какие изменения требуются в существующих услугах с учетом: новых функциональных возможностей и требований; изменений в бизнес-процессах, зависимостях, приоритетах, влиянии и критичности; изменений в объеме транзакций услуги. Транзакция (Transaction) - дискретная функция, выполняемая ИТ-услугой. Например, перевод денег с одного банковского счета на другой. Одна Транзакция может содержать многочисленные добавления, удаления и изменения данных, при этом все они должны быть завершены успешно, в противном случае ни одна из них не должна быть выполнена (т.е. вся транзакция будет отменена); повышения уровня услуги и целевых показателей уровня услуги в связи с новым драйвером у бизнеса, или понижение для старых услуг, которые будут в скором времени замещены; потребностей в дополнительной информации процессов Управления услугами. Информация о требованиях к новым услугам: требуемая функциональность; информация и другие потребности менеджмента; поддерживаемый бизнес-процесс, зависимости, приоритеты, влияние и критичность; требования уровня услуг и целевые показатели уровня услуг; уровни транзакций бизнеса, уровни транзакций услуг, количество пользователей и его предполагаемый рост, типы пользователей; финансовое и стратегическое обоснование для бизнеса; предположение о будущих изменениях, то есть об известных будущих требованиях бизнеса или увеличение темпа роста. уровень мощности для бизнеса, который должен быть представлен[10]. Это минимальный набор информации для начала проектирования. Ее точность и аккуратность первостепенна. Если некорректная и неправильная информация будет использована на этапе Проектирования, то разработанная услуга не будет удовлетворять потребностям бизнеса в конечном итоге. Требования к услугам должны быть документированы. Время, потраченное на это, будет компенсировано отсутствием в дальнейшем споров, дискуссий и разногласий между поставщиком услуг и заказчиком. Стадия определения требований бизнеса заключается в следующем: назначение менеджера проекта, создание проектной команды и утверждение руководства с применением формальной и структурированной методологии; идентификация всех заинтересованных лиц, составление соответствующих документов с их требованиями и выгодами, которые они получат в результате реализации проекта; анализ, документирование, расстановка приоритетов и согласование требований. вычисление и утверждение бюджета\выгод бизнеса; разрешение потенциальных конфликтов между бизнес-единицами и соглашением о корпоративных требованиях; определение процессов для утверждения требований и изменения утвержденных требований; развитие плана взаимодействия с заказчиком, подчеркивание основных отношений между IT и бизнесом, и то, как эти отношения и необходимая связь с заинтересованными сторонами будет управляться[10]. После того, как требования согласованы и утверждены, у них появляется "ценник", то есть можно посчитать стоимость конкретного проекта. Требуется соблюдать баланс между тем, что организация может себе позволить и тем, что она хочет. Реализация некоторых требований может слишком дорого стоить и они должны быть исключены уже на этапе Проектирования. При необходимости все решения об исключении требований к услугам могут быть документированы и согласованы с представителями бизнеса. Обычно сложности возникают при сопоставлении того, что хочет бизнес и бюджета, выделенного под решение, который не принимает в расчет полную стоимость услуги, в том числе расходы на текущее обслуживание. Применяемые документы при проектировании архитектуры и дизайны должны быть четкими, лаконичными, простыми и обоснованными. К сожалению, они часто слишком сложны и носят теоретический характер, а, следовательно, плохо применимы для практики в реальном мире. жүктеу/скачать 1,47 Mb. Достарыңызбен бөлісу:
|