Работу необходимо начинать с составления Технических требований проекта 1С автоматизации (оптимизации или бережливого производства).
На нулевом этапе, т.е. в месте вашего чтения, мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать — пониманием, что бизнес-процесс работает не эффективно. К сожалению, часто руководители этого не видят или не хотят видеть. (Примеры явных неоптимальных бизнес-процессов моих наблюдений на проектах я опишу в будущих публикациях).
Начинать работу необходимо с составления Технических требований (ТТ) проекта 1С автоматизации (оптимизации или бережливого производства).
Какой-либо структуры документа ТТ в ГОСТ Р ИСО/МЭК 12207-2010 вы не найдёте.
«Настоящий стандарт не устанавливает требований к документации в части ее наименований, форматов, определенного содержания и носителей для записи»
ГОСТ Р ИСО/МЭК 12207-2010
Сразу сообщу, что документ ТТ необходим для:
- согласования требуемых функций и их взаимодействия между подразделениями;
- подтверждения директората в необходимости проекта и идентификации Заказчика проекта (должностное лицо предприятия);
- аргументированного основания начала диалога с Исполнителем.
В собственной практике я использую приблизительно вот такой перечень, как на рисунке. Он чем-то схож с техническим заданием, но цель другая. Правда он будет незаменимым помощником в будущем при написании основного документа проекта — технического задания.
Разделов много, но основной целью документа является описание бизнес-требований проекта. Их формулировка, в первую очередь, позволяет сотрудникам предприятия (Заказчику) выработать единую точку зрения на перспективу проекта. Именно тут возникают первые дебаты руководителей подразделений о надобности того или иного функционала и «кто это будет делать».
Вот пример раздела бизнес-требований недавнего документа ТТ производственного предприятия по внедрению 1С:ERP.
Как видите, таблица бизнес-требований содержит участок автоматизации (предметную область), бизнес-требование и приоритет. Бизнес-требования составлены лаконично. Никаких подробностей здесь быть не должно, поскольку это концепт. Детали будут в техническом задании, но именно это первый шаг к самопознанию и благополучию предприятия) Приоритет показывает порядок очерёдности решения описанных проблем.
Кто должен создать документ?
Идеально — штатный сотрудник со знанием проектных технологий и специфики предприятия. Часто такой компетенции на предприятии нет. Освоить! Ничего сложного — это не техническое задание. Если же обращаться к внешнему Исполнителю, то возникает другая неприятность — подрядчик не владеет спецификой предприятия.
На практике я часто встречаю что этот документ не разрабатывают, чем создают первую же ошибкупроекта.
» «Полнота данных бесценна!»
Технические требования»
Это документ требований. Следовательно имеем 2 варианта заполнения. Смотрим на блок-схему.
Указав в ТТ сроки выполнения проекта, технологию, ограничения, вы тем самым предъявляете Исполнителю условия к его ресурсам. Если проект трудо- и/или наукоёмкий, то в тендерных участиях отпадают слабые претенденты, не обладающие производственными мощностями, которые неспособны выполнить по выбранной технологии и в требуемый срок. Тут поставлю сноску — ради проекта многие солгут, что могут. В будущей статье я опишу, как распознать блеф претендента (в конкурсах по автоматизации 1С).
Необходимо указывать сроки — начало и окончание проекта. Дискретность — квартал, если реализация проекта оценивается в более чем 6 месяцев. Можно меньше, но не забывайте что это первичный прогноз, и для помесячного планирования нужны аргументы.
Точная дата окончания проекта стоит лишь в том случае, если масштаб проекта настолько велик, что обещали В.Путину. Но учитывая последние события со строительством нового космодрома «Восточный» и дедлайн — не дедлайн
В ходе поездки на космодром «Восточный» Владимир Путин заявил о нарушении сроков исполнения ряда проектов по космодрому и разрешил перенести первый пуск с «Восточного» на 2024 год.
РИА Новости
Иногда, когда известны некоторые детали проекта — выбор технологии внедрения и наличие опыта по аналогичному проекту, я указываю временную ленту стадий проекта (из MS Project). Это я делаю при движении по «проторенной» дорожке и понимаю шаги. Как видите, вместо термина «Этап проекта» использую «Квант» (для технологии быстрого результата ТБР). Ниже поясню почему.
Допустимые нормы отклонения в реализации проекта я детально опишу в статье про Техническое задание. Там крайне важно понимание границ выхода за сроки проекта.
Выбор технологии
Во-первых: технологию можете не указывать, тем самым предоставляете возможность Исполнителю предложить лучшую на его взгляд. Но если на вашем предприятии (чаще в Группе Компаний) разработаны методики и стандарты проектного управления — надо указывать собственную технологию. При всём их разнообразии — их единицы, остальное «диалекты» :).
Для начала я бы порекомендовал вам ознакомиться со статьёй «Как запускать проекты вовремя». Отрывок:
Кризис. Отставание на 56 дней. Менеджер в панике. К проекту подключается директор студии: лично едет к заказчику и договаривается об увеличении сроков на два месяца. Клиент соглашается, но не готов оплачивать дополнительное время. Студия работает бесплатно. + 60 дней в план
Слово «студия» можно заменить на 1С:Франчайзи. И будет всё так же.
В этой же статье описывается, как я её называю, квантовая технология (c). Квант — достижение неделимого обязательного результата за короткий промежуток времени. Моя любимая и эффективная
Что на этот счет предлагает 1С:
1С:ТБР (Технология быстрого результата)
ТБР — ни месяца без результата!
Как отмечено выше, ТБР — это технология управления проектами внедрения программных продуктов на базе «1С:Предприятие», направленная на получения быстрых, регулярных и качественных результатов, имеющих ценность для заказчика.
Технология Быстрого Результата:
- направлена на минимизацию рисков за счет формализованного жизненного цикла проекта и набора специализированных руководств;
- позволяет снизить транзакционные издержки, связанные с ведением проекта;
- проста в освоении, индустриальна (легко отчуждается, тиражируется и адаптируется для определенной компании);
- доступна как для партнерской сети фирмы «1С», так и для клиентов;
- основывается на богатом опыте участников партнерской сети фирмы «1С», существующих технологиях (стандартное внедрение) и передовом мировом опыте (PMI PMbok, eXtreme Programming).
http://www.1c.ru/news/info.jsp?id=10403
1С:ТСВ (Технология стандартного внедрения)
Это внедрение типового решения без строгой формализации проекта с возможными небольшими доработками (например, внесение/изменение дополнительных отчётов, обработок, печатных форм), не влияющие на структуру базы данных. В силу того, что многие/все бизнес-процессы предприятия накладываются на логику работы программ 1С, то возможно минимальное участие Заказчика.
1С:ТКВ (Технология корпоративного внедрения)
Огромный камень — тяжёлый, неповоротливый, статичный… [Технология основана на правилах проектного управления PMBoK (Project Management Body of Knowledge). Звучит трендово, нежели ГОСТ 34] … и если его захотеть подвинуть — требуется огромные ресурсы и время. Каждый этап описан, согласован набор обязательной документации. Часто с обязательным наличием ТТ (о чём и речь статьи).
Для анализа выбора технологии я использую собственную таблицу.
Поинты помогут вам в выборе. НО! Вашу аналитическую работу никто не отменяет. Вы должны понимать, что есть виды бизнеса где 5 человек требуют ТКВ. Например, дочернее предприятие крупного холдинга занимающееся сервисом — уборкой территории, общепитом, услугами автотранспорта и т.п. — много бизнес-процессов, требующих описания.
Согласование документа
Наличие согласованного документа подтверждает, что директорат ознакомлен (или же выступает инициатором) с намерениями начать диалог автоматизации с исполнителем и осознаёт области и бизнес-требования автоматизации.
Если документ ТТ длительное время не подписывается стоит насторожиться. Возможно инициатор проекта не имеет влияние на принятие решения, либо отсутствует единая точка зрения, либо ТТ создан неудовлетворительно и не раскрывает бизнес-цели в полном объёме.
Если планируется выполнять проект силами привлекаемой организации, то документ ТТ является предметом первичного диалога с претендентами. На основании этого документа вы можете запросить первичные анализы, форматы работ, предварительные оценки и т.п.
За статью +, но не большой.
Интересно было увидеть структуру Вашего ТТ. Еще более интересно увидеть его полный пример.
Кстати, структура Вашего ТТ чем-то напоминает Устав проекта, это объяснимо, т.к. все мы хотим на старте проекта определить правила работы и примерные временные и финансовые границы проекта.
P.S. По оформлению: очень мешает чтению движущаяся вырезка из фильма «Служебный роман» )))
Склонение наименования «Домодедово» является ошибкой, хе-хе
(2) Steelvan,
Спасибо, исправил))
При прочтении возникает странное чувство, что хотя вот автор уже вроде и почти да, но с другой стороны в целом как бы и не совсем, а даже если и взять и посмотреть в общем, целостным взглядом так сказать, то не смотря на то, что многие, очень многие вопросы сразу проясняются, в то же время хочется чтобы в статье было более конкретное объяснение вопроса, который надо сказать, для всех, ну или почти для всех, тем более в такое время как сейчас, когда все меняется развивается, огромадными темпами, даже можно сказать делая семимильные шаги, упускать из виду вещи, хоть и на первый взгляд не совсем существенные, на практике, в реальной жизни, в реальными клиентами, в прямом общении, могут показать себя совсем с другого ракурса.
Да примеров бы ТТ и ФТТ посмотреть было бы хорошо. Ну такой кусок для старта тоже полезен. +1