# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

# Проектирование

Деятельность или [процесс](https://cleverics.ru/digital/kb-glossary/process/), которые определяют требования, а затем определяют решение, способное удовлетворить эти требования.

## Оригинальный английский термин

design

## Подробности

[Проектирование](https://cleverics.ru/digital/kb-glossary/design/) в [ITSM](https://cleverics.ru/digital/kb-glossary/it-service-management/) — это целенаправленная работа по переводу потребностей и ожиданий [заказчика](https://cleverics.ru/digital/kb-glossary/customer/) и других [заинтересованных сторон](https://cleverics.ru/digital/kb-glossary/stakeholder/) в согласованный образ будущего решения. Обычно проектирование начинается с выявления и уточнения требований (включая [требования полезности](https://cleverics.ru/digital/kb-glossary/utility-requirements/) и [требования гарантии](https://cleverics.ru/digital/kb-glossary/warranty-requirements/)), после чего формируется решение: как будет устроена [услуга](https://cleverics.ru/digital/kb-glossary/service/) или [ИТ-услуга](https://cleverics.ru/digital/kb-glossary/it-service/), какие [компоненты](https://cleverics.ru/digital/kb-glossary/component/) и взаимодействия потребуются, какие ограничения действуют и как будет обеспечиваться [ценность](https://cleverics.ru/digital/kb-glossary/value/). В [практике проектирования услуг](https://cleverics.ru/digital/kb-glossary/service-design-practice/) это выражается в создании и уточнении [сервисной архитектуры](https://cleverics.ru/digital/kb-glossary/service-architecture/), определении целевых характеристик [доступности](https://cleverics.ru/digital/kb-glossary/availability/), [производительности](https://cleverics.ru/digital/kb-glossary/performance/), безопасности, а также в описании процессов и [сервисных операций](https://cleverics.ru/digital/kb-glossary/service-action/), необходимых для [предоставления и поддержки](https://cleverics.ru/digital/kb-glossary/deliver-and-support/). [Результаты](https://cleverics.ru/digital/kb-glossary/outcome/) проектирования используются далее в [управлении изменениями](https://cleverics.ru/digital/kb-glossary/change-management/), [управлении релизами](https://cleverics.ru/digital/kb-glossary/release-management-practice/) и [управлении развёртыванием](https://cleverics.ru/digital/kb-glossary/deployment-management-practice/), а также задают основу для управления [уровнем услуг](https://cleverics.ru/digital/kb-glossary/service-level/) и [измерения и отчётности](https://cleverics.ru/digital/kb-glossary/measurement-and-reporting/). При этом проектирование не равно «рисованию схем»: оно включает согласование компромиссов, [оценку риска](https://cleverics.ru/digital/kb-glossary/risk-assessment/) и обеспечение [соответствия требованиям](https://cleverics.ru/digital/kb-glossary/compliance/), [стандартам](https://cleverics.ru/digital/kb-glossary/standard/) и [политике](https://cleverics.ru/digital/kb-glossary/policy/). Вне области термина находятся фактическая реализация решения ([разработка](https://cleverics.ru/digital/kb-glossary/development/) и настройка), проведение [валидации](https://cleverics.ru/digital/kb-glossary/validation/) и тестирования как самостоятельной [активности](https://cleverics.ru/digital/kb-glossary/activity/) и эксплуатационное сопровождение в [рабочей среде](https://cleverics.ru/digital/kb-glossary/live-environment/); проектирование описывает, что и почему должно быть создано, а не выполняет само создание.## Нюансы

Проектирование часто ошибочно отождествляют с разработкой ПО или [развёртыванием](https://cleverics.ru/digital/kb-glossary/deployment/). На [практике](https://cleverics.ru/digital/kb-glossary/practice/) проектирование задаёт целевую структуру и характеристики решения, а разработка и развёртывание реализуют это решение в [средах](https://cleverics.ru/digital/kb-glossary/environment/) и переводят его в рабочую среду через управление [изменениями](https://cleverics.ru/digital/kb-glossary/change/) и [релизами](https://cleverics.ru/digital/kb-glossary/release/). Другая распространённая путаница — между проектированием и [управлением архитектурой](https://cleverics.ru/digital/kb-glossary/architecture-management-practice/): управление [архитектурой](https://cleverics.ru/digital/kb-glossary/architecture/) поддерживает принципы и [целостность](https://cleverics.ru/digital/kb-glossary/integrity/) архитектуры на уровне [организации](https://cleverics.ru/digital/kb-glossary/organization/), тогда как проектирование конкретизирует решение под заданные требования в рамках услуги или [продукта](https://cleverics.ru/digital/kb-glossary/product/). Также проектирование нередко воспринимают как разовую фазу «в начале [проекта](https://cleverics.ru/digital/kb-glossary/project/)»; в современных подходах оно итеративно и может уточняться по мере появления обратной связи и изменения [спроса](https://cleverics.ru/digital/kb-glossary/demand/), однако это не отменяет необходимости фиксировать решения и допущения, чтобы управлять [риском](https://cleverics.ru/digital/kb-glossary/risk/) и [техническим долгом](https://cleverics.ru/digital/kb-glossary/technical-debt/). Типичная [ошибка](https://cleverics.ru/digital/kb-glossary/error/) — фокус только на [полезности](https://cleverics.ru/digital/kb-glossary/utility/) и игнорирование требований [гарантии](https://cleverics.ru/digital/kb-glossary/warranty/): решение может выполнять функции, но быть неприемлемым по доступности, [надёжности](https://cleverics.ru/digital/kb-glossary/reliability/) или [конфиденциальности](https://cleverics.ru/digital/kb-glossary/confidentiality/). Ещё один риск — проектировать «в вакууме», без вовлечения заказчика, [пользователей](https://cleverics.ru/digital/kb-glossary/user/) и [команд поддержки](https://cleverics.ru/digital/kb-glossary/support-team/); тогда возникают несоответствия процессам предоставления и поддержки и завышенные ожидания по уровню услуги. Наконец, проектирование не является валидацией: проверка того, что решение действительно соответствует требованиям, относится к [управлению валидацией и тестированием](https://cleverics.ru/digital/kb-glossary/service-validation-and-testing-practice/), хотя критерии проверки должны быть заложены уже на этапе проектирования.## Примеры

- Проектирование ИТ-услуги удалённого доступа: определение требований полезности, требований гарантии и целевой сервисной архитектуры с учётом конфиденциальности и доступности
- Проектирование процесса управления запросами на обслуживание: описание шагов, ролей сервис-деска и команды поддержки, интеграций с каталогом запросов и метрик измерения и отчётности
- Проектирование решения для мониторинга: определение источников событий, правил корреляции и требований к дашборду для управления мониторингом и событиями
- Проектирование изменения в рабочей среде: выбор модели изменения, оценка риска и определение плана релиза и развёртывания до выполнения RFC
- Проектирование механизма резервного копирования: определение RPO и RTO, требований целостности и плана восстановления как основы для управления непрерывностью услуг

## Рекомендуемые продукты по этой теме

- [ITSM. Основы управления ИТ-услугами](https://edu.cleverics.ru/itsm-foundation?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=ITFO4) — Учебный курс: интенсив с тренером. Самый популярный тренинг по управлению ИТ
- [Apollo 13 — ITSM на практике](https://edu.cleverics.ru/apollo?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=APOLLO) — Деловая игра. Service Desk, управление инцидентами, проблемами, изменениями
- [Altevics](https://cleverics.ru/solutions/altevics?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=altevics) — Современная ITSM/ESM-система