Предприятие требует проект автоматизации? Начните правильно!

23.12.15

Бизнес-анализ - Работа с требованиями

На нулевом этапе мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать, — пониманием, что бизнес-процесс работает неэффективно. К сожалению, часто руководители этого не видят или не хотят видеть. Работу необходимо начинать с составления Технических требований проекта 1С автоматизации (оптимизации или бережливого производства).
 

На нулевом этапе, т.е. в месте вашего чтения, мы не имеем никакого представления о порядке работ, бюджете и сроках достижения статуса «Работает как надо!». Единственное, чем мы можем обладать — пониманием, что бизнес-процесс работает не эффективно. К сожалению, часто руководители этого не видят или не хотят видеть. (Примеры явных неоптимальных бизнес-процессов моих наблюдений на проектах я опишу в будущих публикациях).

Начинать работу необходимо с составления Технических требований (ТТ) проекта 1С автоматизации (оптимизации или бережливого производства).

Какой-либо структуры документа ТТ в ГОСТ Р ИСО/МЭК 12207-2010 вы не найдёте.

«Настоящий стандарт не устанавливает требований к документации в части ее наименований, форматов, определенного содержания и носителей для записи»

ГОСТ Р ИСО/МЭК 12207-2010

Сразу сообщу, что документ ТТ необходим для:

  • согласования требуемых функций и их взаимодействия между подразделениями;
  • подтверждения директората в необходимости проекта и идентификации Заказчика проекта (должностное лицо предприятия);
  • аргументированного основания начала диалога с Исполнителем.

В собственной практике я использую приблизительно вот такой перечень, как на рисунке. Он чем-то схож с техническим заданием, но цель другая. Правда он будет незаменимым помощником в будущем при написании основного документа проекта — технического задания.

ТТ-11

 

Разделов много, но основной целью документа является описание бизнес-требований проекта. Их формулировка, в первую очередь, позволяет сотрудникам предприятия (Заказчику) выработать единую точку зрения на перспективу проекта. Именно тут возникают первые дебаты руководителей подразделений о надобности того или иного функционала и «кто это будет делать».

sr02

 

Вот пример раздела бизнес-требований недавнего документа ТТ производственного предприятия по внедрению 1С:ERP.

ТТ-2

Как видите, таблица бизнес-требований содержит участок автоматизации (предметную область), бизнес-требование и приоритет. Бизнес-требования составлены лаконично. Никаких подробностей здесь быть не должно, поскольку это концепт. Детали будут в техническом задании, но именно это первый шаг к самопознанию и благополучию предприятия)  Приоритет показывает порядок очерёдности решения описанных проблем.

Кто должен создать документ?

Идеально — штатный сотрудник со знанием проектных технологий и специфики предприятия. Часто такой компетенции на предприятии нет. Освоить! Ничего сложного — это не техническое задание. Если же обращаться к внешнему Исполнителю, то возникает другая неприятность — подрядчик не владеет спецификой предприятия.

На практике я часто встречаю что этот документ не разрабатывают, чем создают первую же ошибкупроекта.

» «Полнота данных бесценна!»

Технические требования»

 

Это документ требований. Следовательно имеем 2 варианта заполнения. Смотрим на блок-схему.

canmustTT


Указав в ТТ сроки выполнения проекта, технологию, ограничения, вы тем самым предъявляете Исполнителю условия к его ресурсам. Если проект трудо- и/или наукоёмкий, то в тендерных участиях отпадают слабые претенденты, не обладающие производственными мощностями, которые неспособны выполнить по выбранной технологии и в требуемый срок. Тут поставлю сноску — ради проекта многие солгут, что могут. В будущей статье я опишу, как распознать блеф претендента (в конкурсах по автоматизации 1С).


srokiTT

ukazvoprosНеобходимо указывать сроки — начало и окончание проекта. Дискретность — квартал, если реализация проекта оценивается в более чем 6 месяцев. Можно меньше, но не забывайте что это первичный прогноз, и для помесячного планирования нужны аргументы.

Точная дата окончания проекта стоит лишь в том случае, если масштаб проекта настолько велик, что обещали В.Путину. Но учитывая последние события со строительством нового космодрома «Восточный» и дедлайн — не дедлайн Smile

В ходе поездки на космодром «Восточный» Владимир Путин заявил о нарушении сроков исполнения ряда проектов по космодрому и разрешил перенести первый пуск с «Восточного» на 2016 год.

1301593417

РИА Новости

ukazvnimanieИногда, когда известны некоторые детали проекта — выбор технологии внедрения и наличие опыта по аналогичному проекту, я указываю временную ленту стадий проекта (из MS Project). Это я делаю при движении по «проторенной» дорожке и понимаю шаги. Как видите, вместо термина «Этап проекта» использую «Квант» (для технологии быстрого результата ТБР). Ниже поясню почему.

Допустимые нормы отклонения в реализации проекта я детально опишу в статье про Техническое задание. Там крайне важно понимание границ выхода за сроки проекта.

Выбор технологии

Во-первых: технологию можете не указывать, тем самым предоставляете возможность Исполнителю предложить лучшую на его взгляд. Но если на вашем предприятии (чаще в Группе Компаний) разработаны методики и стандарты проектного управления — надо указывать собственную технологию. При всём их разнообразии — их единицы, остальное «диалекты»  :).

Для начала я бы порекомендовал вам ознакомиться со статьёй «Как запускать проекты вовремя». Отрывок:

Кризис. Отставание на 56 дней. Менеджер в панике. К проекту подключается директор студии: лично едет к заказчику и договаривается об увеличении сроков на два месяца. Клиент соглашается, но не готов оплачивать дополнительное время. Студия работает бесплатно. + 60 дней в план

Слово «студия» можно заменить на 1С:Франчайзи. И будет всё так же.

В этой же статье описывается, как я её называю, квантовая технология (c). Квант — достижение неделимого обязательного результата за короткий промежуток времени. Моя любимая и эффективная Smile

e2d8c449-7a32-4fd7-a0f9-6fe625bc6084

Что на этот счет предлагает 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] … и если его захотеть подвинуть — требуется огромные ресурсы и время.  Каждый этап описан, согласован набор обязательной документации. Часто с обязательным наличием ТТ (о чём и речь статьи).

Для анализа выбора технологии я использую собственную таблицу.

SiteChooseTeh

 

Поинты помогут вам в выборе. НО! Вашу аналитическую работу никто не отменяет. Вы должны понимать, что есть виды бизнеса где 5 человек требуют ТКВ. Например, дочернее предприятие крупного холдинга занимающееся сервисом — уборкой территории, общепитом, услугами автотранспорта и т.п. — много бизнес-процессов, требующих описания.

Согласование документа

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

Если документ ТТ длительное время не подписывается стоит насторожиться. Возможно инициатор проекта не имеет влияние на принятие решения, либо отсутствует единая точка зрения, либо ТТ создан неудовлетворительно и не раскрывает бизнес-цели в полном объёме.

Если планируется выполнять проект силами привлекаемой организации, то документ ТТ является предметом первичного диалога с претендентами. На основании этого документа вы можете запросить первичные анализы, форматы работ, предварительные оценки и т.п.

проектное управление технические требования проекта нормативная документация при проектах личный опыт и наблюдения на производственных предприятиях

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Работа с требованиями Радио Аналитик Бесплатно (free)

В шестом выпуске пятого сезона подкаста Радио “Аналитик“ поговорили про отличия производительности от отказоустойчивости, про способы конкретизировать "медленно" и "быстро", про работу с требованиями к производительности, про знания и навыки, которые для этого необходимы.

11.11.2026    86    0    Radio_Analyst    0    

1

Работа с требованиями Аналитик Бесплатно (free)

Разбираем, почему управление требованиями остается одним из ключевых факторов успеха проекта, и как ошибки на этом этапе приводят к срывам сроков, перегрузке команды и «синдрому скользящей дорожки». Показываем, как превратить сбор требований в понятный процесс: вовлекать заинтересованные стороны, использовать активное слушание, визуализацию, прототипирование и микротребования. Объясняем, как расставлять приоритеты через MoSCoW и матрицу Эйзенхауэра, визуализировать задачи в Jira на Kanban-доске и сохранять фокус даже в условиях постоянных изменений. На практическом кейсе портала кандидата показываем, как системная работа с требованиями помогает довести проект до результата и получить продукт, который не просто используют, но и любят.

28.10.2026    242    0    user1916475    1    

1

Стандарты и документация Разработчик Бесплатно (free)

Рассказываем, зачем компании понадобились паспорт информационной системы и план аварийного восстановления и как за несколько лет эти документы выросли из небольшой таблицы в подробный стандарт. Разбираем их состав, требования к инфраструктуре, информационной безопасности, интеграциям, мониторингу и сценариям восстановления, а также показываем, как этот подход работает на практике. Объясняем, как документирование помогает снизить зависимость от знаний отдельных специалистов, упростить восстановление систем и использовать накопленные данные при создании новых решений. В завершение делимся планами по развитию документации в полноценную ресурсно-сервисную модель.

23.10.2026    361    0    jack_nsk    0    

1

Работа с требованиями Аналитик Бесплатно (free)

ИТ-ландшафт стремительно усложняется: растет число систем и потоков данных между ними, процессы выходят за рамки платформы 1С, а требования к надежности, доступности и безопасности становятся все выше. Поэтому современному аналитику уже недостаточно быть только «переводчиком требований бизнеса» – ему нужно проектировать взаимодействие систем, координировать работу нескольких ИТ-команд и учитывать нефункциональные требования еще до передачи задачи в разработку. Разбираем, почему концептуальный дизайн интеграции входит в зону ответственности аналитика, и какие знания платформы 1С, системного дизайна, баз данных и инженерных практик помогают сократить количество итераций и быстрее находить реализуемые решения. Объясняем, на какие характеристики архитектуры следует обращать особое внимание и как развивать техническую насмотренность, не пытаясь при этом стать экспертом во всех технологиях сразу.

02.10.2026    1344    0    romandredan    26    

10

Работа с требованиями Взгляд со стороны Заказчика Работа с заинтересованными сторонами Аналитик Руководитель проекта Бесплатно (free)

На приемке пользователь может уверенно сказать «все понятно», хотя половину показа он мысленно переводил с языка аналитиков и разработчиков. В статье я подробно расписала, как описывать пользовательские сценарии обычными рабочими словами, что именно давать бизнесу на проверку, как формулировать ожидаемый результат и что фиксировать после приемки, чтобы «да, все хорошо» действительно что-то означало.

01.10.2026    439    0    YA_826532418    0    

5

Работа с требованиями Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Каждый архитектор и руководитель 1С-проектов рано или поздно сталкивается с выбором: продолжать латать старую систему или снести всё до основания и заложить правильный фундамент. Что делать, если появились "золотые гвозди"? Когда система на "пластырях" не работает.

28.09.2026    364    0    nik-boss    2    

1

Работа с требованиями Оценка проекта Аналитик Руководитель проекта Бесплатно (free)

Клиент может попросить оценку уже на первой встрече, когда вместо ТЗ есть только общее описание задачи, а внутри действующего проекта от команды обычно ждут намного более точную цифру. На основании своего опыта, описала, какой информации достаточно для предварительной оценки, что должно быть проработано перед финальной, какие допущения нужно фиксировать и в какой момент вместо точного количества часов лучше назвать диапазон.

25.09.2026    624    0    YA_826532418    6    

5

Стандарты и документация Разработчик Аналитик Россия Бесплатно (free)

Статья посвящена практическому опыту адаптации стандартов разработки фирмы «1С» для работы с ИИ-инструментами. Показано, почему обычного пересказа стандартов недостаточно для надёжной генерации и ревью кода: при сокращении теряются условия применения, исключения, обязательность требований и контекст. Авторы описывают переход к формализованным карточкам правил, содержащим источник, условия, исключения, способ проверки, тяжесть нарушения, возможности автоматического контроля и дату сверки со стандартом. Материал будет полезен руководителям проектов 1С, архитекторам и разработчикам, которые внедряют ИИ в разработку и контроль качества. На реальных тестах показано, как структурированное представление стандартов снижает число пропущенных дефектов, ложных замечаний и потенциально опасных исправлений.

25.09.2026    455    0    Rico17    3    

1
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Vladimir_Konyrev 267 24.12.15 07:49 Сейчас в теме
За статью +, но не большой.

Интересно было увидеть структуру Вашего ТТ. Еще более интересно увидеть его полный пример.
Кстати, структура Вашего ТТ чем-то напоминает Устав проекта, это объяснимо, т.к. все мы хотим на старте проекта определить правила работы и примерные временные и финансовые границы проекта.

P.S. По оформлению: очень мешает чтению движущаяся вырезка из фильма "Служебный роман" )))
2. Steelvan 317 30.12.15 22:52 Сейчас в теме
Склонение наименования "Домодедово" является ошибкой, хе-хе
3. Ingraf 694 12.01.16 16:54 Сейчас в теме
(2) Steelvan,
Спасибо, исправил))
4. Belarus2012 29.01.16 20:28 Сейчас в теме
При прочтении возникает странное чувство, что хотя вот автор уже вроде и почти да, но с другой стороны в целом как бы и не совсем, а даже если и взять и посмотреть в общем, целостным взглядом так сказать, то не смотря на то, что многие, очень многие вопросы сразу проясняются, в то же время хочется чтобы в статье было более конкретное объяснение вопроса, который надо сказать, для всех, ну или почти для всех, тем более в такое время как сейчас, когда все меняется развивается, огромадными темпами, даже можно сказать делая семимильные шаги, упускать из виду вещи, хоть и на первый взгляд не совсем существенные, на практике, в реальной жизни, в реальными клиентами, в прямом общении, могут показать себя совсем с другого ракурса.
5. Светлый ум 509 06.09.19 07:45 Сейчас в теме
Да примеров бы ТТ и ФТТ посмотреть было бы хорошо. Ну такой кусок для старта тоже полезен. +1
Для отправки сообщения требуется регистрация/авторизация