2.5. В разделе «Характеристики объекта автоматизации» приводят:
|
Раздел достаточно простой, но довольно важный.
Почему? Да потому что содержит Scope проекта, или по русски - границы. А их грамотное описание позволит, теоретически, защитить вас от необоснованных хотелок или поможет выйти на следующие этапы по модернизации или масштабированию того, что вы там внедряете.
Я использую следующий общий подход по его написанию:
1. Краткая вводная информация о компании. Берется чаще всего с сайта компании, раздел "О Компании". Типа - Компания А является крупнейшим производителем Х и Y. Включает в себя 2-а завода, 3-и филиала и 150 точек продаж.
2. Краткая вводная информация о пользователях системы и их организационной структуре. Типа - Финансовый департамент имеет централизованную структуру с выделением 3-х филиалов. В Рамках Фин депа выделены специализированные отделы А и Б численностью 150 человек, которые обеспечивают учет и сопровождение договоров.Отделы централизованы и расположены в офисе №2.
3. Краткая информация об автоматизируемом бизнес процессе или тех.процессе или составе оборудования для которого строится АСУ.
Отделы в рамках сопровождения клиентов (CRM) решают следующие задачи:... , выполняют следующие функции... Отделы предоставляют следующую информацию: Клиентам, Смежным подразделениям.
4. Краткая информация об условиях эксплуатации. Почему это важно?
- Потому что вам возможно понадобится защищенное и морозоустойчивое исполнение серверов с питанием от 3-х фаз на 380 вольт. -)
- Или бизнес деятельность, которую вы автоматизируете, осуществляется в соответствии с государственными законами и нормативными актами, которым вы, сюрприз, должны соответствовать.
- Или данные в системе являются секретными... Или еще что...
В данном разделе я описываю
- для оборудования
- условия работы и территориальное размещение
- средства связи и передачи данных
- режимы работы и параметры надежности (это к тому что надежность АСУ не надо делать выше надежности объектов управления)
- режимы обслуживания (а то попадете на суб подряд с обслуживающей организацией)
- для процессов
- требования к соответствию стандартам и законам
- класс обрабатываемой информации (простая, секретная, персональные данные). КстатиЮ с этим маразмом с Персональными данными - обязательно надо писать кто является на вашем объекте оператором ПД и есть ли ПД на объекте или нет.
- режим работы операторов (от этого могут зависеть требования по простою)
Ну и все пункты завершаются ссылками на соответствующие регламентирующие документы. Орг структура, Регламенты, Проекты, Базы данных, другие АСУ. Особое внимание надо уделять регламентирующим документам и стандартам которые устанавливает государство и согласно которым ведется деятельность
Теперь несколько типсов:
1. если вы не заморачиваетесь описанием показателей назначения, имеет смысл сюда впихнуть исходные данные которые вы использовали для расчета стоимости (Люди, филиалы, катастрофоустойчивость, персональные данные, автоматизируемые площадки, используемые средства связи и тп...
2. Если вы вообще не заморачиваетесь ограничитесь пунктами 1-3. Благо их написать не стоит труда
3. В общем и целом этот раздел имеет смысл рассматривать не как обузу, а как обоснование цены вашего предложения.
Ну вот и все. В следующий раз я планирую затронуть вопросы оформления Общих сведений
Этот комментарий был удален автором.
ОтветитьУдалитьДобрый день!
ОтветитьУдалитьМожете поделиться примером, как можно отразить требования касательно персональных данных в ТЗ?
Спасибо!