Пример бизнес требования по автоматизации

На данном этапе сотрудниками компании ELMA разрабатывается техническое задание на автоматизированную систему для оптимизации основных бизнес-процессов компании. Это очень важный этап, т.к. определяет требования к функционалу внедряемой системы ELMA.

С чем можно сравнить необходимость составления техзадания?

Давайте рассмотрим пример с постройкой дома. Вы знаете, какой дом вам нужен: из какого материала, сколько этажей, комнат, какой интерьер вы бы хотели и т.д. Вы можете на пальцах и словах объяснить строителям свои «хотелки», но когда придёте принимать работу, то, скорее всего, обнаружите один из домиков «трёх поросят». Вывод – необходим документ,mформализующий Ваши желания и чётко определяющий работы исполнителей.

Техническое задание на автоматизированную систему управления бизнесом – это документ, согласно которому вы (как заказчик) получите именно тот «дом», который хотели: от исполняемого функционала до интерфейса рабочей системы. И, в то же время, техзадание необходимо исполнителям для оценки объёмов и планирования работ.

Если сравнивать все технические задания на автоматизированную систему управления бизнесом ELMA в различные компании, то невозможно будет найти даже двух одинаковых документов, т.к. не существует двух совершенно одинаково работающих компании (свои цели, свои ключевые показатели, свой ход процедур).

Описание технического задания на автоматизированную систему управления бизнесом ELMA для компании ООО «Ваша мебель» (Проект внедрения)

Проект внедрения системы ELMA в ООО «Ваша мебель» включает в себя несколько частей, а именно:

• Внедрение оперативного управления (задачи, поручения)
• Внедрение электронного документооборота
• Внедрение управления бизнес-процессами организации

Техзадание на внедрение системы ELMA в ООО «Ваша мебель» содержит:

1. Цели автоматизации:

• Повышение лояльности клиентов за счёт качественного и своевременного исполнения заказов;
• Контроль деятельности компании.

2. Перечень объектов под автоматизацию:

Бизнес-процессы:

1. Заказ корпусной мебели
2. Заказ мягкой мебели
3. Заказ типовой корпусной мебели
4. Заявление по корпусной мебели Регистрация заявления
5. Заявление по мягкой мебели
6. Заявление по типовой корпусной мебели

1. Договор на корпусную мебель
2. Договор на мягкую мебель
3. Договор на типовую корпусную мебель
4. Проект
5. Заявление

1. Список заказов
2. Состояние заказа
3. Список заказов менеджера
4. Состояние по закупкам
5. Себестоимость заказа
6. Текущие заявления

Справочники:

Номенклатура фурнитуры и комплектующих
Клиентская база

3. Архитектура решения

Для достижения поставленных целей были выбраны необходимые по функционалу приложения системы ELMA: пакет ELMA ECM+, в состав которой входят платформа ELMA BPM и приложение ELMA:Электронный документооборот, и модуль Интеграции с 1С.

4. Документооборот в системе ELMA для ООО «Ваша мебель».

4.1. Документооборот в системе ELMA осуществляется в рамках пакета ELMA ECM+:

• Модуль ELMA: Электронный документооборот позволяет создавать, обрабатывать и хранить электронные документы. За счёт внедрения данного модуля в компании ведётся регистрация всех важных документов (входящих и исходящих), повышается контроль и скорость работы с документами.
• Платформа ELMA BPM позволяет организовать работу с документами на протяжении всего жизненного цикла: от регистрации до исполнения.

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

4.2. Типы документов ООО «Ваша мебель»

Были выделены следующие типы документов под автоматизацию:

• Договор на корпусную мебель
• Договор на мягкую мебель
• Договор на типовую корпусную мебель
• Проект
• Заявление

В техническом задании обязательно прописываются требования к каждому Типу документов.

Например, рассмотрим Тип документа – «Заявление».

Название типа документа

Шаблон названия документа

Разрешать менять название документа

Источник: www.elma-bpm.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Студия работает бесплатно. + 60 дней в план

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

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

Что на этот счет предлагает 1С:

1С:ТБР (Технология быстрого результата)

ТБР — ни месяца без результата!

Как отмечено выше, ТБР — это технология управления проектами внедрения программных продуктов на базе «1С:Предприятие», направленная на получения быстрых, регулярных и качественных результатов, имеющих ценность для заказчика.

Технология Быстрого Результата:

• направлена на минимизацию рисков за счет формализованного жизненного цикла проекта и набора специализированных руководств;
• позволяет снизить транзакционные издержки, связанные с ведением проекта;
• проста в освоении, индустриальна (легко отчуждается, тиражируется и адаптируется для определенной компании);
• доступна как для партнерской сети фирмы «1С», так и для клиентов;
• основывается на богатом опыте участников партнерской сети фирмы «1С», существующих технологиях (стандартное внедрение) и передовом мировом опыте (PMI PMbok, eXtreme Programming).

1С:ТСВ (Технология стандартного внедрения)

Это внедрение типового решения без строгой формализации проекта с возможными небольшими доработками (например, внесение/изменение дополнительных отчетов, обработок, печатных форм), не влияющие на структуру базы данных. В силу того, что многие/все бизнес-процессы предприятия накладываются на логику работы программ 1С, то возможно минимальное участие Заказчика.

1С:ТКВ (Технология корпоративного внедрения)

Огромный камень — тяжелый, неповоротливый, статичный… [Технология основана на правилах проектного управления PMBoK ( Project Management Body of Knowledge ). Звучит трендово, нежели ГОСТ 34] … и если его захотеть подвинуть — требуется огромные ресурсы и время. Каждый этап описан, согласован набор обязательной документации. Часто с обязательным наличием ТТ (о чем и речь статьи).

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

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

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

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

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

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

• 1С
• внедрение программных продуктов
• техническая документация

Источник: www.klerk.ru

1.1. Формирование требований к автоматизированной системе

Итогом обследования является коммерческое предложение по реализации проекта с рекомендациями по выбору и внедрению ПО, которое также содержит этапы, ориентировочные сроки, объем и стоимость выполняемых работ.

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

Информационное обследование компании

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

• Сбор информации о компании (документации, анкет, интервью и т.д.).
• Анализ и систематизация данных, полученных в ходе первого этапа.
• Представление результатов для согласования с заказчиком.

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

Основными источниками информации для обследования (как для экспресс, так и для информационного) являются анкеты, интервью и внутренняя документация компании-заказчика. Для наилучшей оценки ситуации в компании составляются три вида анкет:

• Анкеты для топ-руководителей;
• Анкеты для линейных руководителей;
• Анкеты для линейного персонала.

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

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

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

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

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

Следующим этапом работ является непосредственно формирование требований к автоматизированной системе.

Требования к программному обеспечению являются совокупностью данных на основании которых проектируется система [10]. Требования составляются на основе информации, полученной в ходе обследования компании, соответственно, чем качественнее были собраны и обработаны данные, тем лучше будут сформированы требования, и тем меньше потребуется корректировок в ходе их согласования. Существуют различные методики формирования требований, несколько из которых будут рассмотрены далее.

Требования по методике Карла Виргеса

В своей работе Карл Виргес выделяет три уровня требований к программному обеспечению: бизнес-требования, пользовательские требования и функциональные требования. При этом, согласно данной методике, на каждом из уровней помимо функциональных, присутствуют нефункциональные требования [11].

• Бизнес-требования – это высокоуровневые требования, содержащие цели заказчиков, спонсоров и организации в целом. Это цели, ради которых разрабатывается система. Данные требования фиксируются в документе концепции и границ или же уставе проекта.
• Пользовательские требования — это требования, описывающие цели и задачи, которые система позволяет решать пользователям. Для иллюстрации данных требований используются диаграммы вариантов использования и сценариев.
• Функциональные требования – требования, определяющие функциональность информационной системы, которая должна быть построена разработчиками, чтобы пользователи могли выполнять задачи для достижения целей сформулированных в рамках бизнес-требований.

• Бизнес-правила не являются требованиями в общепринятом смысле, но они являются источниками для требований к ИС. Бизнес-правилами могут быть политики, стандарты, регламенты и предписания, которые ограничивают или определяют ход бизнес-процессов.
• Атрибуты качества – это требования, которые являются дополнительным описанием функций системы или ее производительности. Такими требованиями могут быть простота использования, логичность, отказоустойчивость, устойчивость к сбоям и прочие.
• Ограничения – технические ограничения на разработку вида и структуры продукта.
• Внешние интерфейсы – требования, описывающие взаимодействие меду системой и пользователем или другим ПО.

Согласно данной методике функциональные требования основываются на описании бизнес-объектов организации (ее структурных единиц, процессов, ролей, систем), а нефункциональные требования формируются по итогам обследования компании путем анкетирования, интервью и наблюдения за работой сотрудников, участвующих в автоматизируемом бизнес-процессе.

FURPS и FURPS+

Данная методика позволяет охватить все аспекты системы и является более широким представлением методики FURPS. Обе методики основаны на методике Карла Виргеса и делят требования на функциональные и нефункциональные, однако далее имеют немного отличающуюся логику деления. Название методики является аббревиатурой [12]:

• Functionality (Функциональность) – это все требования, которые касаются функционального назначения системы. Сюда входят: безопасность, отчетность, лицензирование, ведение журнала и другие.
• Usability (Удобство использования) – это требования, основанные на человеческом факторе. То есть субъективные пожелания пользователей системы. В данные требования могут быть включены требования к интерфейсу (его интуитивная понятность, эстетичность, логичность), к эксплуатационной документации (ее полнота и понятность), а также к защите от ошибок.
• Reliability (Надежность) – данное требование к системе подразумевает ее способность работать в условиях высокой нагрузки и под воздействием неблагоприятных факторов. Требованиями к надежности могут быть доступность системы, отказоустойчивость и восстанавливаемость, время и частота сбоев, точность вычислений.
• Performance (Производительность) – эти требования адресованы к объему информации, который может проходить через систему во время ее работы. Например, пропускная способность, время отклика, потребление ресурсов, масштабируемость и другие.
• Supportability (Поддерживаемость) – это требования к обеспечению технической поддержки, то есть к тому как система может быть адаптирована, совместима с другими системами, конфигурируема. Также к этому типу требований относятся требования к поддержке системой стандартов, языков, валюты, времени, и то, как легко система устанавливается.

В методике FURPS+ помимо требований первоначального стандарта, были добавлены некоторые ограничения:

• Ограничения проектирования – ограничения, которые влияют на границы проектных решений, в соответствии с которыми буде разрабатываться система.
• Ограничения разработки – это ограничения, которые задают необходимые стандарты кодирования: язык программирования, стандарты, инструменты или платформы.
• Ограничения на интерфейсы – требования к взаимодействию с другими системами, которые формируются пользователями.
• Физические ограничения – это ограничения, которые оказывают влияние на аппаратную часть системы (размер, вес, условия работы и т.д)

Как и FURPS, SWEBOK является аббревиатурой (Software Engineering Body of Knowledge). Это документ призванный объединить в себе знания по разработке программного обеспечения и содержащий 10 различных областей знаний, первой из которых является инженерия требований.

Согласно данному документу работа над формированием требований должна проходить в несколько этапов: определение, анализ, спецификация, проверка и управление, а область знаний «Требования к программному обеспечению» состоит из 6 разделов [13]:

• Инженерия требований – это процесс анализа и документирования требований к программному обеспечению, который заключается в преобразовании требований заказчика в их описание и контроль их соблюдения.
• Выявление требований – это процесс сбора информации из различных источников (документов, анкет, интервью), в ходе которого формируются отдельные требования к процессу разработки и системе.
• Анализ требований – процесс во время которого исследуются потребности и цели пользователей, которые сопоставляются с требованиями к системе для устранения конфликтов между требованиями, формирования границ системы и выявления приоритетов. На данном этапе требования разделяются на функциональные и нефункциональные.
• Спецификация требований к ПО – процесс формализации функциональных и нефункциональных требований, требований к взаимодействию с другими системами и компонентами, а также системных требований. В ходе спецификации формируется структура будущего программного обеспечения, его архитектура, логика, требования к функционалу, качеству, эксплуатационной документации.
• Валидация требований – это процесс проверки однозначности, непротиворечивости, полноты и выполнимости требований для того, чтобы с помощью отслеживания источников требований подтвердить, что требования характеризуют именно эту систему.
• Управление требованиями – процесс внедрения требований во все этапы жизненного цикла, контроля реализации требований и корректировка требований при необходимости.

Данные подходы к формированию требований могут быть применены в различных проектах, в зависимости от конкретной ситуации. Так методика Карла Виргеса является одной из первых методик, на которой были основаны ряд других. Методики FURUPS схожи с данной методикой, однако требования в них не привязаны к определенным регламентирующим документам. Последняя методика (SWEBOK) сформулирована в результате сбора и анализа многолетнего опыта разработки программного обеспечения и описывает этапы сбора требований.

Источник: studfile.net