Пишем ТЗ: Что такое Назначение Системы, Цели и Задачи

Этим постом я открываю серию публикаций, а в реальности серию заметок для себя по вопросам написания проектных документов, оформления требований, SRS и концепций и прочей "фигни" которая отравляет жизнь настоящего творца, но без которой сделать проект в России для гос заказчика нереально -). Итак...

Очень часто когда обычных ИТ-шников просят написать VISION на систему на них сходит ступор. С чего начать? Особенно если вас просят начать с ТЗ по ГОСТ34 -). А оно начинается с Назначение, Цели и Задачи. А есть еще Показатели назначения, о которых рекомендуется не писать вообще.  По первой я то же не сразу приобрел легкость бытия, но регулярно встречаю различные перлы на эту тему. Приступим:



Назначение системы - для чего она предназначена (самое простое).
Здесь выдумывать ничего не надо и просто можно указать:

1. какой процесс она автоматизирует (это для систем пользовательских, в которых есть пользователи, например SAP, Почта,1С и тп)  "Назначением системы А является автоматизация процесса В (учета использованных карандашей)"
2. что в системе создается(это для инфраструктурных систем, которые работают без пользователей, например MPLS сеть, ферма VMWare и тп.) "Назначением системы является создание MPLS сети уровня предприятия А".

Различить два типа просто - если у вас есть пользователи/операторы то это 1, если только админы - то это 2.
В чем хитрости? Я вижу тут следующее:

1. Назначений системы не стоит делать несколько;
2. Не стоит писать, что назначением является обеспечение чего либо - чаще всего это цели создания;
3. Систем которые создаются ради "создания" крайне мало, используйте это назначение аккуратно. Классический для меня пример: 1. Создание системы резервного копирования - автоматизация процессов рез копирования; 2. Создание хранилища данных - автоматизация процессов хранения и обработки данных

Цели создания - зачем собственно мы это делаем.

Часто именно здесь можно как совершить непростительные ошибки, так произвести вери гуд впечатление на ЛПР (лицо принимающее решение). 

В первую очередь - что не является целями создания. Целью создания не является собственно само СОЗДАНИЕ. Писать, что целью создания системы является ее создание/развитие\модернизация, оставим Портосу, который сказал - "Я дерусь, потому что я дерусь".
Включить в голове правильное направление мыслей, может помочь ответ на вопрос - "Вот мы создали Систему, а толку?"

Вот несколько самых типовых целей:

• соответствие требованиям регуляторов (например - Закону о персональных данных)
• обеспечение возросших потребностей компании А в пропускной способности сети связи (например для замены 10BaseT на 1000BaseT)
• обеспечение возможности развертывания в компании В централизованной ERP системы (модернизация сетей передачи данных)
• обеспечение  подразделений А-В-С современными средствами соответствующим общемировым практикам ITIL\ITSM (например при внедрении Сервисдеска)
• организация централизованного учета материальных средств и работ по их обслуживанию и сопровождению
• техническое обеспечение  бизнес услуги "По-секундная тарификация"
• снижение трудоемкости подготовки какой-то там отчетности
• повышение доступности ИТ за счет снижения времени обнаружения неисправностей (для систем мониторинга) 
• ну и в таком стиле....

Какие есть тонкости:

• в первую очередь - не пишите в целях то, достижение чего система не в состоянии обеспечить. В первую очередь это ПОВЫШЕНИЕ или ПОНИЖЕНИЕ чего-либо: стоимости владения, доходности, снижение затрат на обслуживание... и тому подобное. Писать достижение экономического эффекта в качестве целей системы - не надо.
• далее - выкиньте весь маркетинг шит, если только вы не пишете бизнес проспект
• если вы пишете в целях улучшение какой-то многофакторной переменной, то используйте фразу "за счет снижения\улучшения такого-то фактора"
• не надо писать много целей, чаще всего достаточно 1-3
• и запомните - цели должны быть достижимыми и измеряемыми. Если вы хотите что-то улучшить запаситесь началом отсчета. Например, замерьте сколько в среднем занимала операция по подготовке квартального отчета, и сколько она стала занимать после внедрения datawarehouse на 1 млн уе. А ведь она может не изменится -) Так что лучше не пишите в ТЗ в целях всякий маркетинг шит
• 
  

Задачи - очень крупно то что мы собственно делаем

Фактически здесь мы указываем артефакты проекта. То что получит заказчик.

Например типовые задачи автоматизации бизнес процесса типовой компании

1. Развертывание системы автоматизации кастомизированной под требования бизнес процесса в составе следующих компонентов:

• центральный портал
• модуль Кадры,
• модуль Зарплата,
• модуль ...

1. Разработка регламента бизнес-процессов Кадры, Зарплата ... (это если вы еще и бизнес процесс внедряете)
2. Разработка пакета отчетности в соответствии с требованиями
3. Обучение персонала 
4. Развертывание системы безопасности на фаирволах и системах обнаружения вторжений
5. далее я думаю понятно...

Из хитростей только одно - не пишите то что делать не собираетесь.

На этом пока все - в следующем посте серии я планирую описать что такое Показатели назначения (это из ТЗ) и что такое Описание объекта автоматизации (это фактически SCOPE системы).