Целевое состояние бизнес процесса ведение справочников

Создание и ведение произвольного числа справочников с полностью настраиваемыми наборами полей.
Встроенный визуальный редактор схем данных (конфигураций) справочников.
Поддержка разнообразных типов данных для поля справочника: как простых (строка, текст, целое число, логический признак, число с плавающей запятой, дата, время, изображение, файл), так и ссылочных (запись справочника, запись каталога, значение из перечисления, запись реестра пользователей). Типовое окно справочника, обеспечивающее представление его записей, открытие их на просмотр и редактирование, вызов операций создания новой записи и удаления текущей записи, а также выбор записи в качестве значения ссылочного поля другого объекта.
Поддержка справочников с иерархией групп. Создание и редактирование дерева групп и распределение по ним записей справочника.
Представление записей справочника выбранной группы или всех групп. Перенос записей справочника между группами. Выбор полей справочника, отображаемых на экране, и определение их порядка.
Фильтрация справочника по любому полю и сочетанию полей, представленных в табличной форме.
Сортировка справочника по любому полю, представленному в табличной форме.
Контроль при вводе значений полей справочника в соответствии с их типами и источниками данных, а также ограничениями, определенными в конфигурации справочника (обязательность поля, минимальное и максимальная длина строки, формат, фильтр, генерация или проверка значения генератором, выбор значения из внешнего объекта с поддержкой ссылочной целостности). Контроль корректности записи справочника.
Установка и интерпретация отношения подчинения между справочниками, позволяющего связывать записи родительского и подчиненного справочников по схемам 1:n и m:n.
Использование справочника как контролируемого словаря для выбора значений с установкой ссылок на них в полях внешних объектов (записях каталога, реестра, другого справочника, реестра пользователей).
Формирование справочника по строковому полю внешнего объекта (каталога, реестра, другого справочника, реестра пользователей) с заменой строк ссылками на записи этого справочника. Динамическое формирование справочника при вводе записей каталога, ссылающихся на него. Преобразование типов данных полей справочника (например, замена символьного представления числовым и наоборот, переход от строки к тексту и др.). Выбор в конфигурации справочника формы представления фильтра по полям других объектов, которые ссылаются на данный справочник. Поддержка JS-скрипта справочника, обеспечивающего широкие возможности для наращивания функциональности программного ядра и типовой конфигурации, адаптируемой к потребностям организации-пользователя. Возможность реализации в скрипте функций, вызываемых при определенных событиях: начало и завершения редактирования записи, начало редактирования поля, обращение к источнику для выбора значения поля, попытка изменения значения поля, очистка значения поля, завершение редактирования поля и др. Возможность вызова из окна справочника любого отчета и процесса, определенного в конфигурации системы, с передачей ему входных данных из контекста.
Ведение журнала операций со справочником.

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

Предлагаем вам ознакомиться с новой статьей, в которой подробно рассказывается, как работать с бизнес‑процессами в программе 1С:CRM.

Применение механизмов бизнес‑процессов позволяет перейти к процессному управлению и качественно улучшить деятельность предприятия за счет автоматизации бизнес‑процессов.

Создание бизнес‑процессов состоит из двух этапов:

1. Основной. Создание карты маршрута и ее настройка.
2. Дополнительный. Создание самого бизнес-процесса.

Создание маршрутной карты

Карта маршрута позволяет определить этапы, условия, точки старта и завершения бизнес‑процесса.

Для того, чтобы создать карту маршрутов:

1. Перейдем в «Настройки», затем «Бизнес-процессы».
2. Выберем «Карты маршрутов бизнес-процессов»:
   • карту можно создать с нуля;
   • можно редактировать уже существующую карту;
   • можно загрузить карту из любого продукта «1С».
3. Нажимаем «Создать».

Настройка этапов карты маршрута бизнес‑процесса объекта

• Для создания новых элементов карты-маршрута используется панель «Вставка элементов схемок», которая расположена в нижней части экрана.
• Для соединения элементов карты-маршрута используются соединительные линии.

Построим логику бизнес-процесса:

1. После построения маршрутной карты стоит проверить, нет ли «брошенных» линий, этапов условий. Для этого нажимаем кнопку «Проверить карту».
2. Завершаем редактирование, нажав на соответствующую кнопку.
3. Присвоим соответствующие условия завершениям бизнес‑процесса:
   • Нажимаем двойным кликом на ячейку «Завершение успех». Выбираем вариант завершения «Успешно».
   • Нажимаем двойным кликом на ячейку «Завершение неудачно». Выбираем вариант завершения «Неудачно».
4. Переходим в раздел «Параметры» и указываем:
   • тип процесса;
   • вид объекта — «Коммерческое предложение клиенту»;
   • реквизит объекта — «Статус».
5. Нажимаем клавишу «Настройка этапов».

6. Сопоставляем реквизит объекта с этапом бизнес‑процесса.

   Обратите внимание: данную настройку необходимо сделать только для процессов объекта.
7. Поскольку в параметрах бизнес-процесса указано «Коммерческое предложение клиенту», а реквизит объекта «Статус», то необходимо сопоставить этап бизнес‑процесса со статусом коммерческого предложения.
8. Настроим описание, которое позволяет сформулировать текст задачи для исполнителя. Далее идет выбор самого исполнителя:
   • «Основной вариант выполнения» — позволяет дать предпочтительный вариант выполнения данного этапа.
   • «Регламент выполнения этапа» — «Укажите длительность отработки этапа согласно регламента» — длительность выполнения этапа в днях, часах, минутах.
   • «Укажите задержку старта следующего этапа» — задает дни, часы, минуты, на которые требуется отложить старт данного этапа.
   • «Запретить исполнителю откладывать следующую задачу» — настройка отключает возможность изменять срок задачи.
   • «Оповещение об истечение срока» — позволяет указать количество дней, часов, минут до окончания этапа для получения уведомления системой.
9. Настроим «Контроль выполнения условий на этапе». Данная настройка позволяет произвести несколько манипуляций:
   • Ввести список документов, которые могут быть созданы на данном этапе.
   • Настроить автоматическое напоминание клиенту, исполнителю, ответственному данного этапа в виде смс или эл. почта.
   • Можно проверить выполнение условий.
10. Настроим наш бизнес-процесс.

Согласование:

• статус: «Не согласовано»;
• описание: «Оценка размера скидки, при необходимости отправить не корректировку»;
• исполнитель: «Руководитель подразделения исполнителя»;
• длительность этапа: 1 день;
• создаваемых документов нет.

Корректировка:

• статус: «Не согласовано»;
• описание: «Скорректировать КП согласно замечаниям руководителя»;
• исполнитель: «Автор бизнес-процесса»;
• длительность этапа: 1 день.

Точка «Завершение успех»:

• Статус: «Действителен».

Точка «Завершение неудачно»:

• Статус: «Отменено».

Настройка параметров карты маршрута бизнес‑процесса объекта

1. Переходим на вкладку «Параметры».

   Обратите внимание: указанные здесь настройки действуют на всю карту маршрута.
2. Проводим необходимые настройки:
   • Настройка гибкости процесса — позволяет завершать бизнес‑процесс на любом этапе досрочно.
   • Разрешена смена текущего этапа — позволяет менять текущий этап, при этом все созданные и невыполненные ранее задачи будут автоматически выполнены.
   • Указывать причину неудачного завершения — позволяет зафиксировать причину неудачного завершения бизнес‑процесса.
   • Редактировать срок выполнения — дает право исполнителю редактировать срок выполнения задачи.
   • Редактировать дату выполнения — дает право исполнителю редактировать дату выполнения задачи.
   • Редактировать исполнителя этапов — дает право редактировать исполнителя этапов.
   • Редактировать сроки выполнения — позволяет ответственному указывать сроки выполнения задач при создании бизнес‑процесса.
   • Динамически рассчитывать сроки выполнения этапов — позволяет, при изменении сроков выполнения задачи, автоматически пересчитывать сроки последующих этапов.
   • Добавлять описание процесса в содержании задачи — постановка задачи будет перенесена в описание задачи.
   • Добавлять историю при содержании задачи — позволяет видеть в содержании задачи всю историю описания и созданные документы.
3. Также в «Дополнительные условия старта» (расширенные настройки) можно изменить условия старта бизнес процесса, если требуется ограничить доступ к нему.

4. Состояние бизнес-процесса можно выбрать из «Действует», «Запланирован», «Отменен».

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

5. Записать и закрыть.

Старт и использование бизнес‑процесса объекта для ведения продажи

Процесс объекта запускается в момент создания объекта.

1. Создадим коммерческое предложение по клиенту «Ассоль ООО».

2. Добавим необходимые номенклатуры.

   

3. Утвердим наш вариант («Операции с вариантами», затем «Утвердить»).
4. Нажимаем «Провести и закрыть».

Программа автоматически запускает бизнес‑процесс по согласованию коммерческого предложения.

1. Первая задача появляется у исполнителя в разделе «Текущие» на вкладке «Мои дела».
2. Исполнитель работает с задачей непосредственно из коммерческого предложения. Он принимает задачу к исполнению, оценивает размер скидки и согласует задачи.
3. В ходе выполнения задач, в коммерческом предложении автоматически меняется статус.

Создание и настройка бизнес‑процесса с использованием созданной маршрутной карты

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

В этом случае создается единственная маршрутная карта и несколько бизнес‑процессов с использованием этой маршрутной карты.

Обратите внимание: в остальных случаях пользователю нет необходимости создавать бизнес‑процесс.

1. Для создания бизнес-процесса переходим в раздел «Процессы», затем «Справочники и настройки».
2. Выбираем «Процессы и проекты».
3. Создаем новый бизнес-процесс «Разбор претензий сервисным отделом».

4. Указываем подразделение: сервисный центр.

   Обратите внимание: если бизнес‑процесс используется всей компанией, поле необходимо оставить пустым.

5. Выбираем карту маршрута — «Разбор претензий сервисным отделом».
6. Настройка этапов и оповещений позволяет для каждого подразделения вести своих исполнителей. Также с помощью этой настройки можно настроить оповещения на каждом этапе для клиента, исполнителя с помощью эл. почты, рассылки или смс.

Запуск и контроль независимого бизнес‑процесса

Независимый бизнес-процесс может стартовать из любого документа системы, например, из интереса по кнопке «создать бизнес‑процесс».

Также в бизнес-процессах, в которых указана настройка «Использовать мастер принятия обращений», возможно стартовать из «Принятие обращения».

Обратите внимание: нужно поставить статус «Действует» для данного бизнес‑процесса.

1. Рассмотрим старт бизнес-процесса «Разбор претензий сервисным отделом» из интереса клиентов.
2. Нажимаем «Создать», затем «Бизнес-процесс».
3. Выбираем «Разбор претензий сервисным центром».
4. В окне старта бизнес-процесса указываем тему.
5. Для старта бизнес-процесса нажимаем кнопку «Запустить».
6. Также можно добавить описание, выбрать подразделение, шаблон и добавить необходимые файлы.
7. Чтобы посмотреть запущенные работы по бизнес-процессам, нужно перейти по гиперссылке «Бизнес‑процессы».
8. После старта бизнес-процесса переходим в «АРМ», затем «Мои дела».
9. Видим, что у исполнителя первого этапа появляется задача , которую требуется решить в рамках этого этапа.

Работа с независимым бизнес‑процессом

1. Чтобы найти эту задачу, переходим в «АРМ», затем «Мои дела» или «Мои продажи».

2. Внутри задачи нажимаем клавишу «Принять».

   Обратите внимание: задачи и историю можно посмотреть в описании. Дополнительную информацию можно увидеть, нажав кнопку «i».

3. Пользователь может перенаправить задачу. Для этого необходимо нажать на человечка, затем выбрать исполнителя и указать причину перенаправления.
4. Если необходимо добавить документы, нажимаем на гиперссылку «Файлы».

5. Если задача занимает много времени, то можно расписать ее на определенные этапы.

   

6. Все действия будут отображаться в календаре сотрудника.
7. После выполнения задачи нажимаем «Выполнить» и фиксируем итоги работы по данному этапу.
8. Переходим на следующий этап бизнес‑процесса «Разбор жалобы», в рамках которого требуется добавить документы, предусмотренные маршрутной картой, и выбрать следующий этап «Жалоба обоснована?».
9. Отметим, что «Да».

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

Воронка продаж используется как оперативный инструмент контроля компании, подразделений и сотрудников.

1. Переходим в раздел «Клиенты», затем «Справочники и настройки».
2. Выбираем «Продажи», затем «Воронки продаж».
3. Для работы с воронкой создаем этап бизнес‑процесса и добавляем его в воронку.
4. Нажимаем «Создать воронку».
5. Указываем наименование.
6. Нажимаем «Создать этап».

7. Открываем воронку «Согласование КП» и видим состав этапов.

   

8. Раскрываем этап воронки. Здесь отображается, какие этапы бизнес‑процесса попали в воронку.
9. Для просмотра воронки переходим в раздел «Клиенты», затем «Воронка продаж».

10. Выбираем необходимую.

    

11. Также можно выбрать показатель, по которому будет просматриваться воронка:
    • по количеству,
    • по сумме.
12. Существует три варианта отображения воронки продаж:

    • Активные. С помощью этого варианта можно получить оперативный отчет о состоянии продаж компании по незавершенным бизнес‑процессам на сегодняшний день, а также увидеть, на каких этапах возникают проблемы.

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

    • Закрытые. Этот вариант отображает закрытые за выбранный период бизнес‑процессы и позволяет оценить эффективность работы по проведению сделок в компании. Данный вариант используется для оценки менеджеров по продаже. Здесь отображается процент конверсии — на каком этапе происходит уменьшение клиентов и какие причины.

      Обратите внимание: здесь отображаются и успешно завершенные, и неудачные бизнес‑процессы.
    • Все является суммой «Активные» и «Закрытые». Позволяет оценить динамику воронки продаж.

Подписывайтесь на канал «ЛК 1С-Рарус отвечает», чтобы не пропустить новые выпуски.

Вам также может понравиться:

• Работа с 1С:CRM: как организовать работу руководителя отдела продаж?
• Работа с 1С:CRM: вы спрашиваете — мы отвечаем
• Работа с 1С:CRM: применение программы в отделе маркетинга
• Работа с 1C:CRM: как собирать накопленную аналитику в программе
• Работа с 1С:CRM: отвечаем на вопросы о сборе накопленной аналитики
• Работа с 1С:CRM: использование продукта в деятельности менеджера по продажам
• Работа с 1С:CRM: блок «Проекты, задачи и взаимодействия» для менеджера отдела продаж

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

Что такое основной бизнес процесс простыми словами

Business Process (в переводе «Бизнес процесс») – это постоянно повторяющаяся в определенное время последовательность (цепочка) действий сотрудников, которая выстроена, в соответствии с политикой компании, и направлена на достижение поставленных целей.

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

Понятие процесса управления и качества его описания – это индикатор профессионализма организации.

История появления термина

Впервые термин «бизнес процессы» появился давно — в 70-х г. г. XX века. Именно тогда предприятия стали переходить к информационным системам и информатизации производственного процесса. Возникла потребность в четкой организации управления предпринимательством и трудовыми ресурсами.

Инструктирование работников стало осуществляться по схеме «человек – человек» и «человек – машина». Все нормы были стандартизированы. Так, нужны были команды, которые бы распознал и человек, и машина.

Первая нотация была создана американскими военными. Постепенно методику стали перенимать и организации. Скоро она стала популярна и в области маркетинга, и среди бизнесменов.

Зачем нужны бизнес процессы

Если компания стремится к качественной системе менеджмента, основанной на стандарте ISO 9001, разработка, описание, внедрение и оптимизация процесса – обязательное условие. В этом случае у предприятия появляется сильное преимущество на конкурентном рынке.

С помощью описания процессов достигают и иные задачи:

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

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

Бизнес процессы отличаются от других процессов, протекающих в компании. В их организации участвуют только люди. Если включается, например, автоматизированная система, речь идет о технологическом процессе.

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

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

Кто описывает бизнес процессы

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

Специалист должен уметь описывать процессы и:

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

Характеристики описания основных бизнес процессов

Описание процессов характеризуется такими параметрами:

1. Наименование и цель. Обычно это одно и то же. Все участники должны будут их знать и понимать. Например, название – «Продажа первой партии нового товара». Цель звучит так же.
2. Исполнитель или владелец инструмента. Это ответственное лицо, которое будет подробно составлять план, доносить его до сотрудников, вести и контролировать процесс его выполнения.
3. Ресурсы, которые используются для достижения поставленных целей.
4. Вход – это те ресурсы, которые поступают извне, сырье.
5. Выход – это произведенные товары или оказываемые услуги. Иногда может получиться не то, что было запланировано, тогда цель на этом этапе меняется.

Еще есть и другие параметры описания, но не обязательны:

• другие участники;
• последовательный порядок операций;
• контрагенты, поставляющие ресурсы;
• конечные пользователи;
• эффективность деятельности;
• уровень риска.

Уровни основных бизнес процессов

Процессы имеют многоуровневое строение:

1. Самый верхний – внешнее воздействие, благодаря которому будут решаться стратегические задачи (например, распределение ресурсов между подразделениями предприятия). Иногда здесь задействованы организационные единицы.
2. Внутреннее воздействие для достижения тактических задач, например, продажа продукции.
3. Процессы внутри структуры, например, когда будет создаваться рабочий проект.
4. Процессы по исполнению задач внутри определенной структуры, например, когда будет разрабатывается план по обслуживанию клиентов.

Классификация бизнес процессов

Классификация основных процессов осуществляется по разным признакам:

Специфика работы:

• процесс производства, когда на выходе будет получаться осязаемый продукт;
• процесс услуг.

Сложность:

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

Структурное место на предприятии:

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

Функции отдела:

• управления;
• распределения финансов;
• организации работы склада;
• логистики;
• производства.

Детализация или комплексность:

• микропроцесс – вид процесса с производством элементов готового продукта, например, стержней для шариковых ручек;
• макропроцесс – выпуск готовой продукции, например, шариковых ручек.

Исполняемость:

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

Описание бизнес процесса

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

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

Кстати! Зарегистрируйтесь в нашем сервисе голосовых рассылок Zvonobot и получите первые 20 звонков — бесплатно 😉

Основные виды бизнес процессов

Все процессы делятся на 6 групп:

1. Основная, представляющая полезную ценность для потребителей.
2. Вспомогательная, обеспечивающая существование основных процессов, но не имеющая ценности для потребителей.
3. Управляющая, предназначенная для контроля над основной и вспомогательной группой процессов и над процессом исполнения целей.
4. Сопутствующая – вспомогательный вид процессов, которые будут приносить дополнительный доход.
5. Группа развития, предназначенная для увеличения производительности и доходов предприятия.
6. Категория совершенствования, направленная на улучшение рабочего процесса, повышения его качества.

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

Правила описания основных бизнес процессов

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

1. Законченность, т.е. любая деятельность должна будет иметь собственную цель, конечный итог (иногда в ходе работы цель может измениться).
2. Краткость. Инструкции должны быть изложены лаконично с обозначением основных этапов работы и задач сотрудников без лишних деталей и сложных терминов. Это обеспечит быструю и слаженную работу всех отделов.
3. Использование общепринятых, типовых обозначений по стандартам IDEF3, BPMN 2.0, BPMN (для преобразования задач в наглядные схемы и таблицы есть специальные программы), чтобы любой участник процесса описания смог прочитать инструкцию и верно истолковать ее.
4. Указание конкретных участников процесса описания и ответственных лиц с четким распределением задач между ними.

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

Уровни анализа

Менеджер самостоятельно определяет, насколько подробно будет описан основной бизнес-процесс. Его можно анализировать на 5 уровнях:

1. Операции. Это самый детализированный уровень, когда будет требоваться перечислять каждое действие.
2. Действия – это ряд операций, в котором должна быть соблюдена определенная последовательность.
3. Процедуры – несколько объединенных действий, выстроенных в определенном порядке для достижения поставленных целей.
4. Базовый уровень, на котором объединяется несколько взаимосвязанных процедур, которые будут служить достижению результатов. Обычно в них участвует несколько сотрудников.
5. Направление работы. Это самый обобщенный уровень, который включает в себя несколько процессов.

Этапы описания

Составление описания бизнес процесса будет осуществляться пошагово в 11 этапов:

1. Определение цели описания. Процесс и описание могут иметь разные цели. На этом этапе нужно будет сформулировать, зачем данному процессу требуется описание. Например, внедрение автоматической системы приема заявок или снижение стоимости производства и т.д.
2. Определение целей описания основного процесса – конечного результата, который нужно будет получить. Целей бывает несколько. Все они должны быть обозначены. Например, покупатель может приобрести товар или отказаться от него. Обоим варианта необходимо описание.
3. Привлечение руководящих сотрудников для обсуждения сформулированных задач и нюансов их выполнения.
4. Донесение информации до сотрудников, которые будут максимально эффективно выполнять задачи. Важно сформулировать их четко, ясно.
5. Расставление приоритетов. Все задачи и действия будут делиться на первостепенные и менее важные. При этом учитывается основная цель, количество ресурсов, время, финансы и прочие факторы при описании.
6. Фиксация начала и конца процесса при описании, их четкое выделение среди прочих элементов.
7. Определение ключевых точек, которые будут влиять на получение результата. Например, ведение переговоров, торг с клиентом, формирование счета на оплату и др. Эти точки могут иметь несколько сценариев, для каждого из которых необходимо описание.
8. Создание черновика предварительного описания, который должны будут получить все заинтересованные лица: руководители, клиенты.
9. Согласование деталей, учет комментариев и пожеланий всех участников процесса описания.
10. Презентация финального описания с внесенными корректировками (все они должны быть согласованы с руководством).
11. Оформление окончательного варианта описания с подробными схемами, планами, моделями и иными документами.

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

Описание процессов может быть в 3 форматах:

1. Текстовом, когда информация изложена, в основном, в виде текста. Это самый распространенный вид описания.
2. Табличном – наглядном виде. Но здесь есть сложности с подготовкой шаблонов.
3. Графическом – самом удобном и понятном варианте в виде моделей и схем.

Каждое описание процесса из них имеет свои плюсы и минусы.

Схема описания бизнес процессов

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

Для построения схемы по описанию процессов могут использоваться специальные программы. Это осуществляется поэтапно:

1. Фиксация границ – начальной и конечной точки основного процесса описания.
2. Выделение основных блоков – базы процесса, в соответствии с их положением в последовательности.
3. Внесение дополнительных элементов – ответвлений, всех возможных путей развития событий.
4. Распределение ролей между участниками. Один сотрудник может одновременно исполнять несколько ролей.
5. Добавление документов: кейсов, презентаций, инструкций, писем и пр.
6. Внесение данных об источниках и программном обеспечении, с помощью которых осуществляется автоматизация процесса описания.
7. Обозначение инструментов, которые могут помочь в достижении целей.
8. Внесение критериев эффективности, с помощью которых будет производиться оценка результата.
9. Моделирование процесса с учетом всех полученных сведений при описании.

Схема описания отображается либо в виде карты (блок-схем), либо маршрута (движение данных и ресурсов в процессе). Для этого применяются стандартные международные формы документирования (нотации).

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

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

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

Анализирование

Сначала всегда необходимо проанализировать существующие процессы, выявить дублирующиеся элементы, оптимизировать задачи. Это необходимо, когда:

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

Чтобы проанализировать текущие процессы, необходимо их описать. Это требуется, если:

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

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

Пошаговое описание

Описание текущего бизнес процесса строится поэтапно:

1. Собирается команда участников этого процесса, включая руководителей.
2. Происходит сбор всей необходимой информации о наличии ресурсов, мощностей, требований к качеству продукта, времени для выполнения заявок и пр.
3. Формулируется конечный итог.
4. Организуется интервью с работниками для определения этапов производства.
5. Создается текстовое или графическое описание.

Управление бизнес процессами

Для реализации потенциала предприятия в полном объеме нужно будет правильно выстроить управление бизнес процессами (BPM). Оно состоит из 4 ступеней:

1. Этап моделирования, когда происходит определение и описание процессов. Также здесь устанавливается ответственность руководителей.
2. Выполнение указанных в описании задач.
3. Контроль работы персонала и движения финансов. Сотрудник на руководящей должности следит за исполнением сроков, качества продукции, равномерной загруженностью кадров, переработками, премированием и штрафами сотрудников.
4. Анализ выполненной работы, сравнение полученного результата с поставленными задачами, выявление ошибок и оптимизация управления процессом.

Качественное управление деятельностью компании определяется бизнес процессами. Если правильно описать и распределить задачи, проконтролировать их выполнение, показатель эффективности будет высоким.

Зарождение BPM

По мере роста и развития компаний стала появляться необходимость в выстраивании правильного контакта отделов. Причем эта потребность возникла как в малом бизнесе, так и на крупных предприятиях.

Прогресс не стоял на месте, в рабочий процесс стали внедряться технологии, предназначенные для облегчения и автоматизации организационной деятельности, повышения ее эффективности и гибкости. Постепенно они переросли в полноценное управление BPM.

Модель зрелости BPM

Зрелость системы управления отражается в модели описания процессов BPM. В ней отображены стадии управленческого процесса. Чем выше уровень, тем более детального и качественного построения управления процессами можно добиться. На низких уровнях наблюдается хаотичность и неуправляемость.

Моделирование бизнес процессов

С помощью построения модели процессов организуется их максимально точное и полное описание. Оно бывает 3 видов:

1. Структурное, которое позволяет исследовать текущие и будущие системы. Оно может быть:
   • функциональным (последовательное построение схемы с использованием конкретных ресурсов);
   • имитационным (учитываются временные интервалы, внутренние и внешние условия);
   • информационным (отображается связь объектов и их характеристики).
2. Ориентированное на объекты без детализации – любые преобразуемые предметы в рабочем процессе.
3. Интегрированное – сочетающее несколько моделей, т.е. комплексное.

Нотации моделирования

В процессе моделирования используются специальные технические условные обозначения (нотации) – единые по всему миру:

ARIS	Его используют при создании, анализировании, внедрении и оптимизации процессов
DFD	Предназначен для использования в макропроцессах бизнеса
UML	Применяется при разработке программного обеспечения, демонстрирует ошибки в структуре
IDEF	Разделяет и объединяет блоки IDEF0, изображает процесс IDEF3
BPMN	Демонстрирует процесс в разных аудиториях
RAD	Предназначена для описания и анализирования функциональных элементов, а также демонстрации их взаимодействия
WFD	Отражает процессы на нижнем уровне, демонстрирует последовательность действий и время их выполнения
ANSI	Это блок-схемы, которые демонстрируют, как идет процесс
ERM	Позволяют сделать описание концепции процессов
SADT	Помогают создавать функциональные модели
FCD	Создан для описания действий, исполнителей, оборудования символами
EPC	В рамках сложного комплексного процесса позволяет определить его вход и выход
STD	Отражает поведение системы во время внешнего воздействия
Дорожки Брюса Силвера	Используется, как дополнение для демонстрации перехода ответственности от одного сотрудника к другому
Unified Modeling Language	Позволяет визуализировать, сконструировать, задокументировать системы и процессы, скачать сформированные документы
Карты потоков ценностей	Отражают потраченные ресурсы и время
Цветные сети Петри	Предназначены для демонстрации переходов, событий, действий

В чем разница между нотациями

Все нотации имеют свои особенности и используются в разных ситуациях. Какие из них выбрать, решает менеджер в процессе моделирования. Обычно используют BPMN или ARIS.

BPMN имеет особенности:

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

Нотацию ARIS выбирают с учетом ее характеристик:

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

На практике использовать BPMN удобнее, так как она поддерживает больше инструментов. С ее помощью можно построить схему как отдельного процесса, так и целой серии.

Платное и бесплатное программное обеспечение и сервисы для создания и описания модели бизнес процесса

Моделирование процессов осуществляется в специальных программах. Самые популярные и удобные из них:

Bizagi Process Modeler	Бесплатный софт для небольших организаций, который можно скачать в интернете. Поддерживает построение диаграмм, позволяет распределить приоритеты. Имеет широкий функционал. Созданную схему можно проверить, изменить ее части, добавить свои элементы, скачать, распечатать. Все сопутствующие документы формируются автоматически и сохраняются в файл. Поддерживает русский язык и одновременную работу нескольких менеджеров.
Visual Paradigm	Платная программа, с помощью которой можно построить схему со всеми корпоративными процессами с взаимосвязанными элементами. Описания можно протестировать или задать их для отдельных составных частей. Для каждого объекта можно установить свои правила.
Elma BPM	Платное ПО, позволяющее следить за работой бизнес-схемы в онлайн-режиме. Задачи можно распределить между конкретными работниками. Поддерживается подключение 1C и загрузка документов.
Fox Manager	Софт, который позволяет создать карту процесса с планом. У поставленных задач можно контролировать степень выполнения и качество, их эффективность и всего рабочего процесса в целом.
ARIS Express	Бесплатная программа для построения моделей и карт. Есть поддержка инструмента Smart Design: после внесения данных схема выдается автоматически. Отдельно созданные модели не могут быть объединены в общий процесс.
Business Studio	Софт от российского разработчика для контролирования исполнения поставленных задач и автоматической генерации документов. Может применяться совместно с другими программами.

Как рассчитать стоимость бизнес процесса

Перед тем как приступить к управлению и оптимизации процессов, необходимо будет проанализировать предстоящие расходы поэтапно:

1. Собрать первичные данные о процессе, сделать его описание, определить, какие операции, как часто и кем будут выполняться. Данные обычно заносятся в таблицу MS Excel с названием столбцов: «Наименование операции», «Коэффициент использования» (частота повторения данной операции), «Исполнитель».
2. Проанализировать, сколько времени будет требоваться на выполнение каждой операции. Для этого можно использовать методы фотографирования (фиксация процесса выполнения операции каждым сотрудником), экспертной оценки персонального бизнес-аналитика, анализа данных с помощью информационной системы (на основе прошлого опыта). На практике часто применяются комбинированные способы. Полученные данные заносятся в таблицу в графу «Время исполнения операции».
3. Подсчет стоимости ресурсов. Для этого рассчитывается, сколько стоит 1 минута работы данного сотрудника (исходя из размера его заработной платы). Затем это значение умножается на время исполнения операции. Полученное значение заносится в таблицу в графу «Стоимость ресурсов за 1 мин». Для получения полной картины стоимости процесса необходимо добавить все остальные статьи расходов: арендную плату, закупку расходных материалов и пр., но без излишней детализации, так как этот этап может затянуться.
4. Подсчет стоимости всего процесса с учетом полученных данных. Для этого необходимо рассчитать, во сколько обходится выполнение одной операции (стоимость минуты времени работника умножается на длительность выполнения задачи). Эти данные нужно занести в таблицу в графу «Стоимость 1 операции», а затем заполнить столбец «Стоимость операций за месяц». Путем сложения значений в последнем столбце можно получить стоимость всего процесса. При этом нужно учитывать, что подобный расчет может иметь большие погрешности.
5. Анализирование стоимости процесса. Когда цена каждой операции будет наглядно отображена в таблице, у руководства обычно появляется желание ее удешевить. Сделать это можно с помощью полного исключения данной операции из процесса (нужно проанализировать, насколько она необходима для получения результата), использования более дешевых ресурсов или менее квалифицированных кадров, ускорения выполнения операций, упрощения рабочего процесса.
6. Анализирование нагрузки на работников. Для этого учитываются не только операции данного процесса, но и все остальные функции сотрудников. Расчеты помогают понять, насколько та или иная операция трудозатратная, а также распределить нагрузку равномерно между участниками.

Внедрение бизнес процессов

Внедряемый процесс может быть как новым, так и уже существующим, но в обновленном виде. В любой ситуации эта процедура происходит поэтапно:

1. Знакомство персонала с новой системой, чтобы они могли ориентироватся не результат.
2. Презентация преимуществ, выгоды и эффективности использования системы.
3. Тестовый запуск программы на одном сотруднике или в одном отделе.
4. Проведение обучения других сотрудников при положительных результатах тестирования.
5. Полноценный запуск процесса.
6. Управление процессом, осуществление контроля над работой персонала и соблюдением алгоритмов новой системы. Этим занимается руководитель или специальный менеджер.

Еще на этапе внедрения нужно, чтобы каждый сотрудник работал по новой схеме.

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

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

1. «Здравый смысл», когда:
   • удаляются дублирующиеся операции;
   • исключается лишний контроль;
   • автоматизируются часто повторяющиеся операции;
   • равномерно распределяются ресурсы;
   • корректируются все составляющие процесса: материалы, технологии и пр.;
   • процесс максимально упрощается;
   • все операции стандартизируются;
   • назначается параллельное выполнение задач, процесс ускоряется;
   • продолжительность операций и расходов на них сокращаются.
2. «Бережливое производство», когда:
   • минимизируются паузы в рабочем процессе (простой машин, согласование заказа и пр.);
   • исключается производство излишков;
   • нерациональные действия сотрудников сводятся к минимуму;
   • сокращаются перемещения работников для сохранения времени;
   • выпускаемая продукция страхуется на предмет появления возможных дефектов;
   • обеспечивается достаточный объем ресурсов.

Оптимизация процесса происходит вскоре после его внедрения.

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

Чтобы оптимизировать внедренный процесс, часто требуется его автоматизация – использование специального ПО для ускорения, упрощения и облегчения выполнения задач.

Автоматизация помогает при:

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

Для автоматизации используются различные программы (CRM с поддержкой звонков клиентам прямо из системы, ERP). Руководство делает выбор на основе поставленных задач.

Плюсы внедрения процессного управления

Управление процессами и их автоматизация имеет преимущества:

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

Реинжиниринг и постоянное совершенствование

Реинжиниринг – это кардинальная перестройка бизнес процессов.

У каждой организации своя специфика и свой порядок этой процедуры, но есть 5 основных шагов:

1. Определение потребностей организации, выявление слабых мест.
2. Формирование группы ответственных специалистов из своих или персональных привлеченных работников.
3. Планирование основных процессов на основе проблем, потребностей клиентов, задач предприятия.
4. Смена подхода для улучшения рабочего процесса.
5. Подключение сотрудников к тестированию процессов и его полноценному запуску.

Реинжиниринг позволяет осуществлять качественное управление бизнес процессами на предприятии, оперативно решать проблемы по мере их поступления. Так, можно будет оптимизировать до 20% всех процессов в компании.

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

• непрерывными изменениями;
• постепенным внедрением новой системы;
• командной деятельностью;
• широким охватом всех отделов предприятия;
• минимизацией дефектов с работой на опережение.

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

Пример удачного анализа и оптимизации бизнес процессов

На предприятии по производству молочной продукции был проведен анализ управления процессами. В ходе него были выявлены проблемы:

• долгая доставка до прилавков магазинов, продукция доходила до потребителей несвежей, что изменило отношение покупателей к бренду;
• простой производственного цеха из-за задержек поставки молока.

После этого были сформулированы задачи:

1. Уменьшить срок доставки товара до 5 ч.
2. Обеспечить своевременную доставку молока в цеха.

Оптимизация процесса позволила предпринять меры:

1. Сменить поставщика молока.
2. Приобрести дополнительные автомобили для оперативной отправки продукции и нанять водителей.

Ошибки при внедрении систем управления

При внедрении системы управления следует учитывать возможные ошибки:

1. Неправильная формулировка цели и задач.
2. Отсутствие согласованности между подразделениями.
3. Иррациональные желания, не соответствующие возможностям.
4. Чрезмерная детализация процесса.
5. Описание всех операций и процессов на предприятии.
6. Игнорирование общепринятых условных обозначений с использованием своих нотаций.
7. Желание получить прибыль от каждого процесса.
8. Формирование идеальной схемы процесса.

Ситуации, когда бизнес процессы нужно описывать

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

1. Резкий рост объемов производства. В период развития возрастает нагрузка на предприятие, нанимаются новые сотрудники, расширяется ассортимент. При наличии описанных процессов все эти действия упорядочены и доступны для всех новых работников. Управление осуществляется более эффективно.
2. Производство, требующее сложных, многоэтапных действий. Каждое из них должно быть четко описано.
3. Открытие новых филиалов по франшизе. Без описания процессов это сделать нельзя, у партнеров должны быть четкие инструкции с полной детализацией рабочего процесса, чтобы применять его на практике.
4. Оптимизация финансов, уменьшение расходов на выпуск товаров, выявление ненужных трат.
5. Подготовка к дальнейшему развитию предприятия, его расширению.

Как бизнес процессы могут быть оптимизированы и усовершенствованы

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

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

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

Помимо этого оптимизация требуется, когда нужно:

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

Где можно обучиться управлению бизнес процессами

Бизнес процессами занимается персональный бизнес-аналитик. Получить профильное образование можно различными способами:

1. Непрофильные вузы с направлениями «Экономика», «Менеджмент».
2. Профильные учебные заведения со специализацией «Предпринимательство».
3. Курсы с государственной поддержкой, т.е. бесплатные для слушателей. В каждом регионе есть свои представительства.
4. Курсы от «Сбера» и Google – лучший бесплатный вариант для получения образования по бизнесу в интернете. Бонусные уровни открываются после прохождения тестирования на сайте. А в блоге постоянно публикуются полезные статьи по теме.
5. Платные онлайн-курсы от «Синергия», Skillbox.ru, «Нетологии» и пр. с получением официального сертификата по e mail.

Заключение

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

Отзывы о бизнес процессах

«У меня небольшое мебельное производство. Сначала я стабильно получал прибыль, но потом случился кризис. Доходы становились все меньше и меньше. Самостоятельно обнаружить проблему не удавалось. После того как был приглашен персональный бизнес-аналитик и было организовано управление процессами, ситуация сразу изменилась. Так, были повышены цены на готовую продукцию, организована перестановка кадров (уволены низкоквалифицированные работники и наняты хорошие специалисты), расширен ассортимент, открыта новая точка продаж»

Александр, 40 лет (Санкт-Петербург)

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

Алексей, 35 лет, (Уфа)

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

Сергей, 32 года, (Москва)

Полезные книги

1. Свод знаний по управлению бизнес процессами. BPM CBOK 3.0
2. Бизнес процессы. Инструменты совершенствования (Б. Андерсен)
3. Управление бизнес процессами. Практическое руководство по реализации проектов (Д. Джестон, Й. Нелис)
4. Учитесь видеть бизнес процессы. Построение карт потоков создания ценности (М.Ротер, Д.Шук)

Литература о принципах и идеологии бизнес-процессов:

1. Критическая цепь (Э. Голдратт)
2. Серия «Цель» (Э. Голдратт)
3. Дао Тойота (Д. Лайкер)
4. Организация как система. Принципы построения устойчивого бизнеса Эдварда Деминга (Г. Нив)
5. Кайдзен. Ключ к успеху японских компаний (М. Имаи)

Книги про оптимизацию:

1. Быстрее, лучше, дешевле: девять методов реинжиниринга бизнес процессов (М. Хаммер)
2. Оптимизация бизнес процессов. Документирование, анализ, управление, оптимизация (Д. Харрингтон)
3. Практическое руководство по реинжинирингу бизнес процессов (М. Робсон, Ф. Уллах)
4. Реинжиниринг корпорации: манифест революции в бизнесе (М. Хаммер, Дж. Чампи)
5. Руководство по улучшению бизнес процессов. Harvard Business School.
6. Производство без потерь для рабочих. Институт комплексных стратегических исследований.

Книги о системном мышлении:

1. Системность во всем. Универсальная технология повышения эффективности (С. Карпентер)
2. Искусство системного мышления (Д. О. Коннор)
3. Системное мышление. Как управлять хаосом и сложными процессами. Платформа для моделирования архитектуры бизнеса (Дж. Гараедаги)
4. Ключевые показатели менеджмента (К. Уолш)
5. Азбука системного мышления (Д. Медоуз)

Книги о применении процессов:

1. Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию (У. Детмер)
2. Найти идею. Введение в ТРИЗ (Г. Альтшуллер)
3. Бережливое производство + шесть сигм в сфере услуг (Майкл Джордж)
4. Теория ограничений в действии (Э. Шрагенхайм)
5. Действенное видение. Как обратить текущий объем продаж в чистую прибыль (Д. Кендалл)

Содержание:

Введение

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

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

Тема представленной работы: «Проектирование реализации операций бизнес-процесса «Продажи».

Цель проектирования заключается в повышении уровня информатизации предприятия в области учета продаж.

Объектом исследования был выбран магазин бытовой техники.

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

1 Аналитическая часть

1.1 Выбор комплекса задач автоматизации

В качестве объекта автоматизации выбран магазин бытовой техники. Магазин предлагает своим клиентам высококачественную бытовую технику от ведущих европейских брендов.

Магазин создан в 2017 году. Организационная форма – общество с ограниченной ответственностью. В штате сотрудников находится 56 человек.

В ходе анализа предметной области была выявлена следующая миссия магазина: «Магазин должен предлагать покупателям только высококачественную бытовую технику».

Стратегия развития магазина ориентирована на выполнение следующих задач:

1. Увеличение оборота товара в пять раз к концу 2020 года;
2. Увеличение доли рынка к концу 2020 года;
3. Поддержание рентабельности на уровне 15-20% путём пристального внимания к расходам и стоимости проданных товаров;
4. Стимулирование осведомлённости потенциальных клиентов через упоминания в печатных изданиях и интернет-ресурсах.
5. Открытие новых путей реализации продукции

Магазин имеет следующую организационную структуру (рисунок 1.1).

Рисунок 1.1 – Организационная структура магазина

Общее руководство организацией осуществляет генеральный директор.

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

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

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

В рамках представленной курсовой работы планируется автоматизация работы отдела продаж. К основным функциям отдела продаж относят:

1. Отпуск товара со склада;
2. Оформление заказов;
3. Ведение базы данных (товаров, категорий, производителей, клиентов);
4. Оформление расходных документов.

Рассмотрим некоторые технико-экономические показатели магазина, таблица 1.1.

Таблица 1.1 Технико-экономические показатели

№ пп	Наименование характеристики (показателя)	Значение показателя на 01.11.2019
1.	Количество клиентов	1000
2.	Количество постоянных клиентов	500
3.	Количество товарных групп	300
4.	Количество брендов, с которыми сотрудничает компания	400
5.	Количество контрагентов, с которыми сотрудничает компания	100
8.	Количество сотрудников	25
9.	Количество филиалов в России	5
10.	Количество филиалов за рубежом	0
11.	Среднее количество продаж в год	2000

1.2 Характеристика существующих бизнес-процессов

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

В то же время, товаровед занимается ведением базы данных производителей, товаров и проделанных операций:

1. Ведет учет количества товара на складе;
2. Добавляет данные о новом товаре, либо редактирует данные уже имеющегося на складе товара;
3. Составляет отчеты о проделанных операциях.

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

С помощью CASE-средства BPWin построим модель бизнес-процесса «Продажа бытовой техники». Контекстная модель построена в методоолгии IDEF0. В IDEF0 модели процесса предоставляются в виде иерархической совокупности взаимодействующих функций (работ) и стрелок. Входная информация преобразуется в выходной сигнал, с помощью чего или кого регламентируется в выполнение определённой функции. Основным компонентом модели является блок и стрелки. Функциональный блок изображается в виде прямоугольника и обозначает собой некоторую конкретную функцию в рамках рассматриваемой системы. Второй элемент диаграммы — стрелка, она бывает четырёх типов: вход, выход, механизм, управление.

Главной компонентой диаграммы является «Продажа бытовой техники». Входные потоки для работы представляют собой: «Заказ», «Оплата заказа», «Информация о технике». На выходе формируются информационные потоки «Выполненный заказ», «Чек», «Расходная накладная» и «Прайс-лист». На диаграмме присутствуют также затунелированные (относящиеся ко всем сущностям декомпозиции) стрелки управления «Устав организации», «Нормативная документация» и стрелки механизмы «Менеджер» и «Товаровед».

Контекстная диаграмма изображена на рисунке 1.2.

Рисунок 1.2 – Контекстная диаграмма

Рисунок 1.3 – IDEF0, первый уровень декомпозиции

Модель DFD или диаграмма потоков данных представляет собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления- продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение объектов (data flow), хранение объектов (datastores), поставка и распространение объектов. DFD декомпозиции второго уровня представлены на рисунках 1.4, 1.5.

Рисунок 1.4 – DFD, «Оформление заказа», второй уровень декомпозиции

Рисунок 1.5 – DFD, «Формирование прайс-листа», второй уровень декомпозиции

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

Рисунок 1.6 – IDEF3, «Выполнение заказа», второй уровень декомпозиции

1.3 Характеристика документооборота, возникающего при решении задачи

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

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

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

Узкое место 1:

Отсутствие структуры данных, единой системы хранения и обработки приводит к следующим проблемам:

1. Сложность оперативного получения необходимой информации о продажах и товарах;
2. Неверный расчет потребностей в товарах из-за некорректных или противоречивых данных;
3. Периодическое отсутствие необходимых товаров на складе;
4. Большие временные затраты на подсчет остатков и формирование потребностей.
5. Повторный ввод информации, данных о товарах и контрагентах.

Предложения:

1. Организовать учет продаж и остатков на административной панели разрабатываемого приложения.
2. Отражать динамику продаж мебели в административной панели разрабатываемого приложения.
3. Отражать остатки каждого товара на складе в административной панели разрабатываемого приложения
4. Организовать хранение данных о контрагентах в базе данных с возможностью редактирования этих данных в административной панели разрабатываемого приложения

Узкое место 2:

Сложность поиска товара.

1. При заполнении расходных, приходных накладных и других документов, приходится искать товар в огромном списке товаров склада.
2. При определении наличия товара на складе для презентации его клиенту также приходится искать товар в огромном списке товаров склада.

Предложения:

1. Отображать категории товаров с возможностью просмотра товаров выбранной категории.
2. Отображать информацию о товарах с возможностью фильтра и сортировки данных о товарах магазина.

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

Рисунок 1.7 — Схема обработки заявки

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

Для большей наглядности рассмотрим данные, представленные в таблице 1.2.

Таблица 1.2 – Трудозатраты на обработку заявок

Наименование работы	Трудозатраты
Сбор информации от клиента	15 мин
Поиск и выбор товара	15 мин
Расчет стоимости накладной	10 мин
Заполнение документов	10 мин
Оформление оплаты	10 мин
Итого:	60 мин

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

Таким образом цель представленной работы – спроектировать автоматизированное рабочее место менеджера магазина бытовой техники. Пользователями такой системы могут быть продавцы и кладовщики. Опишем основные функции, которые должна выполнять данная система:

1. Ведение базы данных контрагентов с подробными данными о них, в базе данных должна храниться информация о клиентах и сотрудниках магазина.
2. Ведение базы данных всех произошедших операций продажи товара, в базе данных должна храниться реестр расходных накладных.
3. Ведение справочников наименований, категорий и производителей товаров.
4. Получение статистической информации (графики продаж товаров по наименованию, категориям и производителям).
5. Получение печатных форм расходных накладных.

1.4 Обоснование проектных решений по информационному обеспечению

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

В качестве модели базы данных выбрана реляционная модель. Требования к БД: оптимизированная структура, соответствие третьей форме нормализации таблиц, поддержка обеспечения целостности данных, контроль и предотвращение занесения некорректной информации.

Классификатор является стандартным кодовым языком документов автоматизированных систем. Для нашей задачи классификаторами будут являться:

1. Код сотрудника;
2. Код клиента;
3. Номер накладной;
4. Код товара;
5. Код производителя;
6. Код категории.

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

Для разрабатываемой системы необходимо спроектировать следующие экранные формы:

1. Форма для работы с товарами;
2. Форма для работы с клиентами;
3. Форма для работы с сотрудниками;
4. Форма для работы с накладным;
5. Форма для предоставления статистической информации.

1.5 Обоснование проектных решений по программному обеспечению

Классификация СУБД по способу доступа к базе данных является самой распространенной. В файл-серверных СУБД файлы размещаются на файл-сервере. СУБД находится на каждом клиентском компьютере. Доступ СУБД к данным происходит через локальную сеть. Преимуществом такой СУБД является низкая нагрузка на процессор файл сервера. А вот недостатков будет больше, чем преимуществ. К ним относятся:

• локальная сеть долго загружается;
• затруднено или полностью невозможно централизованное управление;
• слабое обеспечение высокой надежностью, высокой доступностью и высокой безопасностью.

Такая архитектура СУБД обычно применятся в локальных приложениях, так как в них низкая интенсивность обработки данных и низкие пиковые нагрузки на БД. На данный момент файл-серверная СУБД считается устаревшей, а ее использование в более крупных системах является недостатком.

Клиент-серверные СУБД. Такую СУБД располагают на сервере вместе с базой данных. Доступ к базе данных происходит в монопольном режиме. Запросы на обработку данных осуществляются клиент-серверной СУБД. Недостатком этой СУБД является повышенное требование к серверу. А вот достоинств будет больше:

• локальная сеть менее перегружена
• централизованное управление более удобно
• СУБД обеспечена высокой надежностью, доступностью и безопасностью.

С появлением специализированных СУБД появилась возможность реализации модели доступа к удаленной базе данных — модели сервера баз данных. В этом случае ядро СУБД функционирует на сервере, прикладная программа на клиенте, а протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса «клиент-сервер».

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

В качестве архитектуры для проектирования ИС «Продажи бытовой техники» выбрана именно клиент-серверная архитектура.

В приведённых ниже таблицах 1.4 – 1.7 отмечено наличие или отсутствие тех или иных возможностей в некоторых популярных сегодня языках программирования. Столбцы упорядочены по алфавиту. Если возможность в языке недоступна напрямую, но может быть эмулирована с помощью других средств, то в таблице отмечено, что её нет.

При заполнении таблицы учтены только фактические данные, при том, что наличие возможности не обязательно является преимуществом языка, а отсутствие – недостатком.

Таблица 1.4– Условные обозначения

Условные обозначения
+	Указанная возможность присутствует
—	Указанная возможность отсутствует
+/-	Возможность поддерживается не полностью
-/+	Возможность поддерживается очень ограниченно
?	Нет данных
N/A	Постановка вопроса не применима к языку

Таблица 1.5 – Типы и структуры данных

Возможность	Язык
C	C++	C#	JavaScript	Perl	PHP	VB.NET	Delphi
Кортежи	—	+/-	+	—	+	+/-	+/-	—
Алгебраические типы данных	—	—	—	N/A	N/A	N/A	—	-/+
Многомерные массивы	+	+	+	+/-	+/-	+/-	+	+
Динамические массивы	—	+	+/-	+/-	+/-	+/-	+	+
Ассоциативные массивы	—	+	+	+	+	+	+	+/-
Контроль границ массивов	—	+/-	+	N/A	N/A	+/-	+	+
Цикл foreach	—	+	+	+	+	+	+	+
Списковые включения	—	—	-/+	—	?	—	+	—
Целые числа произвольной длины	—	—	+	—	+	+/-	+	—
Целые числа с контролем границ	—	—	—	—	—	—	—	+

Таблица 1.6 – Компилятор/интерпретатор

Возможность	Язык
C	C++	C#	JavaScript	Perl	PHP	VB.NET	Delphi
Open-source компилятор (интерпретатор)	+	+	+	+	+	+	+	+
Возможность компиляции	+	+	+	+	+	+	+	+
Bootstrapping	+	+	+	+	?	N/A	?	+
Многопоточная компиляция	+	+	—	?	?	?	+	?
Интерпретатор командной строки	-/+	+/-	+	+	+	+	+	+/-
Условная компиляция	+	+	+	-/+	+	+	+	+

Таблица 1.7 – Функциональные возможности

Возможность	Язык
C	C++	C#	JavaScript	Perl	PHP	VB.NET	Delphi
Декларации чистоты функций	—	—	—	—	—	—	—	—
First class functions	-/+	+	+	+	+	—	?	+/-
Анонимные функции	—	+	+	+	+	+	+	+/-
Лексические замыкания	—	+	+	+	+	+	+	+/-
Частичное применение	—	+/-	?	+	—	—	?	?
Каррирование	—	+/-	+	+	+	+	—	+/-

Для выполнения данного дипломного проекта был выбран C#. В качестве интерактивной среды разработки использовалась Visual Studio, которая имеет весь необходимый функционал для создания графических интерфейсов пользователя.MicrosoftVisualStudio — линейка продуктов компании Microsoft, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии WindowsForms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Windows, WindowsMobile, Windows CE, .NET Framework и т.д.

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

Примерами СУБД, которые выполняют выше описанные функции как раз и являются MS Access и SQL Server. (Различных СУБД конечно намного больше, но мы рассматриваем лишь эти две). Сначала, как положено, выясним, что это за такие СУБД и где применяются.

Таблица 1.8 – Место применения

MS Access	SQL Server
Microsoft Access – это настольная система управления реляционными базами данных (СУБД), предназначенная для работы на автономном персональном компьютере (ПК) или локальной вычислительной сети под управлением семейства операционных систем Microsoft Windows. Обычно используется на малых предприятиях, для небольшого количества информации.	Microsoft SQL Server – система управления реляционными базами данных (СУБД). Основной используемый язык запросов – Transact SQL. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия.

Как видим, с точки зрения масштабности использования SQL Server 2005 превосходит MS Access, так как может хранить больший объем информации и использоваться на различных, как малых, так и крупных по масштабам предприятиях. MS Access же, зачастую применяется для обучения и для работы небольших организаций, так как она очень удобна в использовании и не требует каких-то особых знаний, времени на ее освоение требуется обычно мало.

Таблица 1.9 – Возможности СУБД

MS Access

SQL Server 2005

К основным возможностям СУБД Microsoft Access можно отнести следующие: Проектирование базовых объектов – двумерные таблицы с полями разных типов данных. Создание связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей. Ввод, хранение, просмотр, сортировка, изменение и выборка данных из таблиц с использованием различных средств контроля информации, индексирования таблиц и аппарата алгебры логики. Создание, модификация и использование производных объектов (запросов, форм и отчетов).

SQL Server 2005 представляет собой интегрированное решение по управлению и анализу данных, которое поможет организациям различного масштаба: Строить, развертывать и управлять промышленными приложениями, которые являются более безопасными, масштабируемыми и надежными. Увеличивать продуктивность информационных технологий, уменьшая сложность построения, развертывания и управления приложениями по работе с базами данных. Разделять данные между платформами, приложениями и устройствами для облегчения соединения внутренних и внешних систем. Контролировать стоимость, не жертвуя качеством выполнения, доступностью, масштабируемостью и безопасностью.

В качестве СУБД в учреждении используется Microsoft SQL Server. Microsoft SQL Server – одна из наиболее мощных СУБД архитектуры клиент-сервер. Эта СУБД позволяет удовлетворять такие требования, предъявляемые к системам распределенной обработке данных, как тиражирование данных, параллельная обработка, поддержка больших баз данных на относительно не дорогих аппаратных платформах при сохранении несмежного управления.

2 Проектная часть

2.1 Информационная модель и её описание

Информационная модель системы представлена на рисунке 2.1.

Рисунок 2.1 – Информационная модель системы

Опишем информационную модель:

• • 1. Авторизация. Администратор авторизуется в системе. Введенные администратором данные для авторизации проверяются в таблице сотрудников;
    2. Редактирование перечня пользователей. Администратор добавляет нового менеджера в систему. Добавляется запись в таблице сотрудников;
    3. Авторизация. Менеджер авторизуется в системе. Введенные менеджером данные для авторизации проверяются в таблице сотрудников;
    4. Редактирование перечня товаров. Добавляется запись в таблицу товаров;
    5. Оформление накладной. Менеджер создаёт новую расходную накладную. Выбираются товары из прайс-листа, вводится их количество, данные о товарах поступают из таблицы товаров;
    6. Печать накладной. Менеджер печатает расходную накладную;
    7. Печать чека. Менеджер печатает чек;

2.2 Характеристика нормативно-справочной, входной и оперативной информации

В качестве входной информации используются следующие сведения о:

1. Клиентах и сотрудниках магазина.
2. Всех произошедших операций продажи товара, в базе данных должна храниться реестр расходных накладных.
3. Справочниках наименований, категорий и производителей товаров.

2.3 Характеристика результатной информации

Выходными данными системы являются:

1. Получение статистической информации (графики продаж товаров по наименованию, категориям и производителям).
2. Получение печатных форм расходных накладных.
3. Результаты поиска и сортировки данных, представленные в табличной форме.

2.4 Общие положения

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

1. Ведение базы данных контрагентов с подробными данными о них, в базе данных должна храниться информация о клиентах и сотрудниках магазина.
2. Ведение базы данных всех произошедших операций продажи товара, в базе данных должна храниться реестр расходных накладных.
3. Ведение справочников наименований, категорий и производителей товаров.
4. Получение статистической информации (графики продаж товаров по наименованию, категориям и производителям).
5. Получение печатных форм расходных накладных.

Структурная схема информационной системы представлена на рисунке 2.2

Рисунок 2.2 – Структурная схема информационной системы

Таким образом, в состав информационной системы входят:

1. Клиентское приложение,
2. Подсистема учета справочников,
3. Подсистема учета контрагентов,
4. Подсистема ведения операций,
5. База данных.

Дерево функций для каждой подсистемы представлено на рисунках 2.3-2.5.

ы

Рисунок 2.3 – Дерево функций учет контрагентов

Рисунок 2.4 – Дерево функций ведение операций

Рисунок 2.5 – Дерево функций учет справочников

На рисунке 2.6 представлен сценарий диалога при редактировании данных таблицы БД.

Рисунок 2.6 – Сценарий диалога

2.5 Характеристика базы данных

ER-модель (уровень «сущность-связь») представлена на рисунке 2.7.

Рисунок 2.7  ER-модель

Сведения о типах сущностей приведены в таблице 2.1.

Таблица 2.1 – Сведения о типах сущностей

№	Имя сущности	Описание	Тип
1	Категория	Список категорий товаров магазина	Сильный
2	Клиент	Список клиентов	Сильный
3	Производитель	Список производителей	Сильный
4	Сотрудник	Список сотрудников магазина	Сильный
5	Покупатель	Список покупателей магазина	Сильный
6	Товар	Справочник товаров магазина	Слабый
7	Расход	Реестр расходных накладных	Слабый

Для устранения связей N:M была добавлена вспомогательная сущность «СоставРасхода».

Сведения о типах связей приведены в таблице 2.2.

Таблица 2.2 – Сведения о типах связей

Тип сущности	Тип связи	Тип сущности	Кардинальность
Категория	Не идентифицирующая	Товар	1:N
Клиент	Не идентифицирующая	Расход	1:N
Производитель	Не идентифицирующая	Товар	1:N
Товар	Не идентифицирующая	СоставРасхода	1:N
Сотрудник	Не идентифицирующая	Расход	1:N
Покупатель	Не идентифицирующая	Расход	1:N

Логическая FA-модель (уровень атрибутов) представлена на рисунке 2.8.

Рисунок 2.8 Логическая FA-модель

Разработанная модель находится в 3-й нормальной форме.

В качестве СУБД выбрана MS SQL Server.

Физическая FA-модель (уровень атрибутов) представлена на рисунке 2.9.

Рисунок 2.9 Физическая FA-модель

Описание модели приведено в таблицах 2.3-2.14.

Таблица «Категория» содержит сведения о категориях товара.

Таблица 2.3 – Структура таблицы «Категория»

Наименование	Тип поля	Размер поля	Ключ или индекс
КатегорияНомер	Int, автоинкремент	4	Первичный ключ
Наименование	varchar	40

Таблица 2.4 – Структура таблицы «Производитель»

Наименование	Тип поля	Размер поля	Ключ или индекс
ПроизводительНомер	Int, автоинкремент	4	Первичный ключ
Производитель	varchar	40

Таблица «Товар» содержит сведения о наименованиях товара.

Таблица 2.5 – Структура таблицы «Товар»

Наименование	Тип поля	Размер поля	Ключ или индекс
ТоварНомер	Int, автоинкремент	4	Первичный ключ
КатегорияНомер	Int	4	Внешний ключ (таблица «Категория»)
ПроизводительНомер	Int	4	Внешний ключ (таблица «Производитель»)
Наименование	varchar	40
Артикул	varchar	40
Цена	Int	4

Таблица «СоставРасхода» содержит сведения о составе расходной накладной.

Таблица 2.6 – Структура таблицы «СоставРасхода»

Наименование	Тип поля	Размер поля	Ключ или индекс
СоставНомер	Int, автоинкремент	4	Первичный ключ
ОстатокНомер	Int	4	Внешний ключ (таблица «Остаток»)
РасходНомер	Int	4	Внешний ключ (таблица «Расход»)
Количество	Int	4

Таблица «Расход» содержит сведения о расходных накладных магазина.

Таблица 2.7 – Структура таблицы «Расход»

Наименование	Тип поля	Размер поля	Ключ или индекс
ПриходНомер	Int, автоинкремент	4	Первичный ключ
СотрудникНомер	Int	4	Внешний ключ (таблица «Сотрудник»)
ПокупательНомер	Int	4	Внешний ключ (таблица «Покупатель»)
Сумма	Int	4
Дата	date	3
Статус	varchar	40	«Заказ» или «Продано»

Таблица «Сотрудник» содержит сведения о сотрудниках магазина.

Таблица 2.8 – Структура таблицы «Сотрудник»

Наименование	Тип поля	Размер поля	Ключ или индекс
СотрудникНомер	Int, автоинкремент	4	Первичный ключ
ФИО	varchar	40
Телефон	varchar	40

Таблица «Покупатель» содержит сведения о покупателях товара.

Таблица 2.9 – Структура таблицы «Покупатель»

Наименование	Тип поля	Размер поля	Ключ или индекс
ПокупательНомер	Int, автоинкремент	4	Первичный ключ
ФИО	varchar	40
Почта	varchar	40
Телефон	varchar	40

В SQL Server создали новую базу данных appliances, рисунок 2.10

Рисунок 2.10 – Создание базы данных appliances

Выполнили в SQL Server Management Studio, сгенерированный в ERWin, ddl-скрипт, Рисунок 2.11.

Рисунок 2.12 – Выполнение в SQL Management Studio ddl-скрипта

В результате выполнения ddl-скрипта получили таблицы базы данных, которые по своей структуре соответствуют физической модели данных, Рисунок 2.13.

Рисунок 2.13 – Таблицы базы данных appliances

Построили схему данных разработанной базы данных, рисунки 2.14, 2.15.

Рисунок 2.14 – Построение схемы данных

Рисунок 2.15 –Схема данных

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

SumSaleMerch – сумма проданных товаров по наименованию,

SumSaleProducer – сумма проданных товаров по производителю,

SumSaleCategory — сумма проданных товаров по категории.

2.6 Структурная схема пакета

Приложение реализовано в среде разработки Microsoft Visual Studio на языке C#. Графический интерфейс пользователя реализован с использованием интерфейса программирования Windows Forms.

Для создания приложения в Visual Studio были использованы следующие компоненты:

1. Для вывода представлений в формы использовался компонент dataGridView;
2. Для управления таблицей использовался компонент BindingNavigator;
3. Для ввода и редактирования полей, значения которых берутся из других таблиц , используется компонент СomboBox;
4. orgDataSet — обеспечивает подключение формы к БД на сервере;
5. Lebel – для нанесения надписей;
6. GroupBox – группирующая рамка и другие компоненты.

При настройке подключения к базе данных в проекте, выбран источник данных, рисунок 2.16.

Рисунок 2.16 – Выбор источника данных

Настроенный источник данных представлен на рисунке 2.17.

Рисунок 2.17 – Настроенный источник данных

Структура модулей ИС представлена на рисунке 2.18.

Рисунок 2.18 — Структура модулей ИС

2.7 Описание программных модулей

Модуль «frmMain.cs» – главный модуль приложения, обеспечивает переход на все ниже описанные модули посредством меню, рисунок 2.19. На форме расположены компоненты для ввода данных авторизации (textbox1, textbpx2), кнопка для авторизации в системе (button1) и главное меню программы (menuStrip1).

Рисунок 2.19 – Главная форма frmMain.cs

«frmMerch.cs» отвечает за работу с таблицей «Товар», рисунок 2.20.

Рисунок 2.20 – Форма frmMerch.cs

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

Также на форме расположены компоненты кнопки для редактирования данных таблицы, рисунок 2.21.

Рисунок 2.21 – Кнопки редактирования

За соединение с базой данных отвечает компонент orgDataSet. За получение данных из таблицы «Товар» используются компоненты merchTableAdapter, merchBindingSource. За получение данных из таблицы «Категория» (выбор категории из выпадающего списка при редактировании записи о товаре) используются компоненты categoryTableAdapter, categoryBindingSource. За получение данных из таблицы «Производитель» (выбор категории из выпадающего списка при редактировании записи о товаре) используются компоненты producerTableAdapter, producerBindingSource. За перемещение по записям таблицы отвечает компонент bindingNavigator.

«frmWorker.cs» отвечает за работу с таблицей «Сотрудник». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы «frmMerch.cs».

«frmClient.cs» отвечает за работу с таблицей «Покупатель». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы «frmMerch.cs».

«frmProducer.cs»отвечает за работу с таблицей «Производитель». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы «frmMerch.cs».

«frmClient.cs» отвечает за работу с таблицей «Клиент». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы «frmMerch.cs».

«frmExpense.cs» отвечает за работу с таблицами «Расход» и «СоставРасхода», рисунок 2.22.

Рисунок 2.22 – Форма frmExpense.cs

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

Также на форме расположены компоненты кнопки для редактирования данных основной таблицы, проведения накладной на склад и печати накладной, рисунок 2.23. И кнопки для работы с вспомогательной таблицей, рисунок 2.24.

Рисунок 2.23 – Кнопки для работы с основной таблицей

Рисунок 2.24 – Кнопки для работы с вспомогательной таблицей

За соединение с базой данных отвечает компонент orgDataSet. За получение данных из таблиц используются компоненты TableAdapter, BindingSource. За перемещение по записям таблицы отвечает компонент bindingNavigator.

«frmStat1.cs» отвечает за вывод статистики продаж товаров по категориям. Статистика выводится с помощью компонента chart.

«frmStat2.cs» отвечает за вывод статистики продаж товаров по наименованиям. Статистика выводится с помощью компонента chart.

«frmStat3.cs» отвечает за вывод статистики продаж товаров по производителям. Статистика выводится с помощью компонента chart.

2.8 Контрольный пример реализации проекта и его описание

По запуску приложения на экран выводится главная форма (логин и пароль для авторизации «admin», «master»), рисунок 2.25.

Рисунок 2.25 – Главная форма

Редактирование и просмотр данных о производителях представлен на рисунке 2.26.

Рисунок 2.26 – Форма «Производители»

Редактирование и просмотр данных о товарах осуществляется на формах «Товары», «Категории», рисунках 2.27- 2.28.

Рисунок 2.27 – Форма «Товары»

Рисунок 2.28 – Форма «Категории»

Редактирование и просмотр данных о контрагентах осуществляется на формах «Сотрудники», «Покупатели», рисунки 2.29- 2.30.

Рисунок 2.29 – Форма «Сотрудники»

Рисунок 2.30 – Форма «Покупатели»

Редактирование и просмотр данных о накладных осуществляется на формах «Продажи», рисунок 2.31. При обновлении данных (кнопка «Обновить») подсчитывается сумма накладной.

Рисунок 2.31 – Форма «Продажи»

Печатная форма накладной представлена на рисунке 2.32.

Рисунок 2.32 – Печатная форма «Расходная накладная»

Статистика продаж представлена на рисунках 2.33-2.35.

Рисунок 2.33 – Статистика продаж по категориям

Рисунок 2.34 – Статистика продаж по наименованию

Рисунок 2.35 – Статистика продаж по производителям

Заключение

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

В ходе выполнения курсовой работы был спроектирован пользовательский интерфейс для базы данных «Продажа бытовой техники».

Автоматизированная система поддерживает все операции, связанные с учетом, обработкой и предоставлением необходимых данных. Данная система обеспечивает ввод, удаление, хранение и редактирование информации, которая содержится в таблицах данных.

Результатами разработки являются:

— информационное обеспечение ИС в формате СУБД MS SQL Server;

— пользовательский интерфейс ИС, включающий экранные формы для работы со справочными, оперативными данными и отчетными данными;

— формы документов и отчетной документации для автоматизированной подготовки на рабочем месте требуемой информации;

— запросы, обеспечивающие формирование данных для первичных и отчетных документов.

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

Реализация системы проводилась с использованием инструментальных средств Visual Studio. в сочетании с СУБД MS SQL Server. При написании программы основное внимание было уделено удобству работы пользователя и построению дружественного интерфейса.

Приложение 1

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Динман М. С++. Освой на примерах. — Спб.: BHV-CПб, 2016. — 384 с.
2. В.Г. Елиферов, В.В. Репин. Процессный подход к управлению. Моделирование бизнес-процессов. – М.:Манн, Иванов и Фербер, 2013
3. Павловская Т.А. C/C++ Программирование на языке высокого уровня. — Спб.: Питер, 2015. — 464 с.
4. Лафоре Р. Объектно-ориентированное программирование в С++ (Object-Oriented Programming in C++, 4/e). — 4-е изд. — Спб.: Питер, 2016. — 928 с.
5. Виктор Зиборов «C# 2010 на примерах» Спб.: БХВ-Петербург Год издания: 2010
6. Дэн Рамел «C# .NET. Справочник программиста» Издательство: Эком Год издания: 2014
7. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. – Приемы объектно-ориентированного проектирования. Паттерны проектирования. – Спб.: Питер, 2011. – 368 с.
8. Грэхем Иан Объектно-ориентированные методы. Принципы и практика = Object-Oriented Methods: Principles & Practice. — 3-е изд. — М.: «Вильямс», 2014. — С. 840.
9. Петцольд, Ч. Программирование для Microsoft Windows на C++ В 2-х томах Том 1. /Ч. Петцольд. Пер. с англ. М.: Издательский дом «Русская редакция»,2012. – 576 с.
10. Петцольд, Ч. Программирование для Microsoft Windows на C++. В 2-х томах. Том 2. /Ч. Петцольд. Пер. с англ. М.: Издательский дом «Русская редакция»,2012. – 624 с.
11. Роберт Виейра «Программирование баз данных в Microsoft SQL Server», г. Москва, изд. «Диалектика», 2012 г.
12. Астахова И. Ф. «СУБД: язык SQL в примерах и задачах», г. Москва, изд. «Физматлит», 2011г.
13. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2012.
14. Глушаков С. В., Ломотько Д. В. Базы данных, 2012. 415 с.
15. Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2011. 268 с.
16. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф. Проектирование экономических информационных систем, 2012.
17. Мишинин А. И. Теория экономических информационных систем, М.: Финансы и статистика, 4-е издание 2007.
18. Петров В.Н. Информационные системы. Спб.: Питер, 2011.

Часть 1. Ведение справочников и объектов ТОиР»

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

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

Собственно, мы решили все-таки сделать попытку и описать в первом приближении наиболее понятные процессы в виде модели «какдолжно быть», которой должна соответствовать любая современная организация ТОиР. Эта модель разработана с учетом нашего собственного опыта обследований и проектирования процессов для большого количества предприятий, а также на основе анализа зарубежного опыта реализации передовых практик, который доступен в соответствующей профессиональной литературе. Очень часто проблемой при проектировании новых процессов является то, что люди, которые их проектируют, никогда в них не работали, и понять, на базе чего делать передовую систему, зачастую не могут Данная статья является первой в серии публикаций, где мы расскажем о собственной «идеальной модели» и обсудим прикладные вопросы ее применимости. Сама модель разработана с использованием специального инструмента моделирования — Business Studio и позволяет сравнительно быстро адаптировать типовые процессы под конкретное предприятие, но при этом оставляя общее «ядро» логики управления.

Общая идеология построения типовых бизнес-процессов Prostoev.NET

Для эффективного управления техническим обслуживанием и ремонтом (ТОиР), а также упрощения процедуры проектирования и внедрения процессного подхода к управлению ТОиР, ООО «Простоев.НЕТ» сформирована модель «A0 Деятельность по поддержанию надежности, проведению ТОиР технологических систем и оборудования», состоящая из 10 типовых процессов:

А1 Ведение справочников и объектов ТОиР в ИС (информационной системе);
А2 Регистрация эксплуатационных показателей;
А3 Поддержание надежности оборудования;
A4 Диагностика;
А5 Планирование работ по ТОиР;
А6 Управление работами по ТОиР;
А7 Обеспечение промышленной безопасности при выполнении работ по ТОиР;
А8 Выполнение работ по ТОиР;
А9 Обеспечение работ по ТОиР запасными частями и инструментами;
A10 Управление финансами, экономикой и бухгалтерией в области ТОиР.

А1 Ведение справочников и объектов ТОиР в ИС (информационной системе)	Сам процесс управления построен на представлении оборудования в виде неких записей (справочников и данных). Полнота описания оборудования позволяет гарантировать, что сам процесс управления его состоянием будет привязан именно к этому оборудованию. С учетом того, что с точки зрения процессов ТОиР оборудование попадает в них как данность, мы не описываем всю цепочку (от определения требований к характеристикам, сами процессы изготовления, испытания, строительство). В большинстве случаев описание объекта происходит из паспорта либо «вживую» у самого объекта.
А2 Регистрация эксплуатационных показателей	После того как оборудование и технологические системы описаны, можно начинать работу по фиксации параметров эксплуатации. К ним мы относим наработку, пуски-остановы. Именно эта информация необходима для запуска счетчиков планирования работ по ТОиР.
А3 Поддержание надежности оборудования	В процессе эксплуатации мы наблюдаем за всеми несоответствиями в работе оборудования, фиксируем и анализируем их. Именно на этом этапе формируется реальная статистика работы (и отказов) оборудования, которая должна быть использована при планировании предупредительных работ по ТОиР. Ведь мы планируем не ради того, чтобы наши планы ППР соответствовали неким усредненным нормативам, не правда ли?
A4 Диагностика	Именно налаженные процессы управления надежностью приводят нас к необходимости диагностировать отдельные виды дефектов, чтобы предупреждать отказы или знать о времени их возникновения.
А5 Планирование работ по ТОиР	Очень важный момент в построении всей нашей модели заключается в том, что только зная результаты, получаемые в вышестоящих проектах, можно говорить, что у нас есть основа для планирования. Планирование в нашей модели представляет собой группу процессов определения плановой потребности в ресурсах (люди, запчасти, инструменты, время простоя) на горизонтах планирования от нескольких лет до месяца.
А6 Управление работами по ТОиР	Следующая группа процессов после планирования позволяет уже более точно организовать выполнение спланированных работ с учетом реальных условий выполнения работ. Обычно горизонты этого планирования — неделя и дни.
А7 Обеспечение промышленной безопасности при выполнении работ по ТОиР	После определения состава работ и объектов, где они должны проводиться, реализуются процессы обеспечения промышленной безопасности.
А8 Выполнение работ по ТОиР	После того как работа определена, реализуется сам процесс выполнения, в ходе которого фиксируется вся необходимая информация, необходимая для контроля работ на этом этапе. После завершения работы она должна быть отражена в виде закрытых документов или записей в информационной системе.
А9 Обеспечение работ по ТОиР запасными частями и инструментами	Наличие планов работ с полным пониманием, что и когда нам потребуется, позволяет эффективно организовать процесс обеспечения ТМЦ.
A10 Управление финансами, экономикой и бухгалтерией в области ТОиР	Поскольку вся наша модель построена на идее ресурсного планирования, то в любой момент времени мы можем оценить полную стоимость работ и реализовать, таким образом, весь комплекс задач, связанных с финансами для ТОиР. То, что эти процессы в нашей модели условно находятся на последнем шаге, не означает, что они не такие важные. Это просто подчеркивает, что мы используем именно ресурсный метод планирования, где первична оценка состояния оборудования и определение планов работ, а не оценка денег.

Взаимосвязь процессов на верхнем уровне отражена на диаграмме «A0 Деятельность по поддержанию надежности, проведению ТОиР технологических систем и оборудования» (рис. 1).

А1 Ведение справочников и объектов ТОиР в ИС

Итак, первой группой процессов в нашей модели является А1 Ведение справочников и объектов ТОиР в ИС.

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

Чтобы иметь возможность планировать ремонт или ТО конкретной обслуживаемой единицы оборудования, а также вести учет ремонтной истории (дефекты, отказы, параметры состояния, наработка), необходимо чтобы эта единица была описана в системе (паспортизирована), поэтому процесс «А1 Ведение справочников и объектов ТОиР в ИС» является первым в приведенной модели. Он состоит из следующих подпроцессов (рис. 2):

A1.1 Ведение единых классификаторов и справочников;
A1.2 Ведение реестра систем и позиций;
A1.3 Ведение реестра оборудования. Рассмотрим более подробно подпроцесс «A1.1 Ведение единых классификаторов и справочников» (рис. 3).

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

В приведенной модели за указанные процессы отвечает отдел нормативно справочной информации (НСИ), структура которого представлена на рис. 4. Для небольших организаций функции специалиста НСИ по ТОиР может выполнять один из наиболее продвинутых пользователей в отделе, который занимается непосредственно планированием и выполнением работ по ТОиР.

Основными справочниками, которые необходимо вести в процессе работы, являются:

• классификатор оборудования;
• группы моделей оборудования;
• модели;
• атрибуты;
• узлы;
• дефекты;
• типовые воздействия;
• типовые ремонтные операции;
• специальности и квалификации;
• машины и механизмы;
• типовые счетчики;
• стратегии ТОиР;
• ТМЦ;
• подрядчики.

Пример классификатора оборудования приведен в табл. 1, пример справочника атрибутов и узлов — в табл. 2 и 3 соответственно. Процедура процесса «A1.1 Ведение единых классификаторов и справочников» такова:

1. При необходимости внесения изменений в справочники специалист НСИ осуществляет проверку на обоснованность заявки на создание новых записей в классификаторах и справочниках и либо принимает ее к исполнению, либо, если в существующих справочниках есть записи, соответствующие запрашиваемой, отклоняет заявку. Специалист НСИ может обратиться за консультацией к технологическому персоналу;
2. Специалист НСИ создает/изменяет записи в соответствующих классификаторах и справочниках, например, создает:
   • класс — насосы;
   • подкласс — центробежные насосы;
   • назначает подклассу соответствующие атрибуты — производительность м3 в час и т.д.;
   • узлы — рабочее колесо, корпус и т. д;
   • операции — демонтаж, чистка, монтаж и т.д.;
   • воздействия — ТО, ТР, КР;
   • модель — SМК 2х3х11Н;
   • типовые ТМЦ — вал, крышка корпуса и т.д.

Код класса	Наименование класса	Код подкласса	Наименование подкласса
01	Аппараты	71	Аппараты емкостные
01	Аппараты	72	Аппараты с внутренними устройствами
01	Аппараты	73	Аппараты с мешалкой
01	Аппараты	74	Аппараты колонные
02	Емкостное оборудование	08	Газгольдеры мокрые
02	Емкостное оборудование	09	Газгольдеры шаровые
02	Емкостное оборудование	16	Резервуары
02	Емкостное оборудование	17	Резервуары изотермические

Класс	Подкласс	Атрибут
Компрессоры	Винтовые компрессоры	Частота вращения 1, об/мин
Компрессоры	Винтовые компрессоры	Частота вращения 2, об/мин
Компрессоры	Поршневые компрессоры	Диаметр поршня (плунжера), мм
Компрессоры	Поршневые компрессоры	Количество поршневых групп
Котельное оборудование	(общий на класс)	Вид топлива
Котельное оборудование	(общий на класс)	Возможность вып. ВО
Котельное оборудование	(общий на класс)	Давление испытаний, МПа
Котельное оборудование	(общий на класс)	Дата окончания продления
Котельное оборудование	(общий на класс)	Диаметр, м

Код	Типовые узлы
У01	Бак расширительный
У02	Барабан
У03	Блок питания
У04	Вентилятор
У05	Гидроцилиндр

В процессе «A1.2 Ведение реестра систем позиций» (рис. 6) изменяется или указывается место новой технологической позиции в иерархии систем и технических позиций. Иерархия представляет собой совокупность элементов данных, расположенных в порядке их подчинения и образующих по структуре перевернутое дерево. Иерархия должна наглядно отображать существующие и устоявшиеся логические связи между техническими системами, подразделениями, а также расположением оборудования. С использованием иерархий решаются следующие типовые задачи управления и учета работ по ТОиР:

• поиск объектов по дереву;
• определение взаимосвязи объектов ТОиР;
• сбор затрат на ТОиР по дереву на вышестоящие объекты путем суммирования затрат на нижестоящие;
• определение критичности оборудования с точки зрения системы, в которую они входят.

Для описания процессов ТОиР обычно используются следующие виды иерархий:

• иерархия систем — отражает структуру технических систем предприятия;
• иерархия организации — отражает организационную структуру предприятия;
• иерархия расположения — отражает структуру территориального расположения оборудования.

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

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

В процессе «A1.3 Ведение реестра оборудования» изменяются или вводятся новые данные по единице оборудования.

Единицы оборудования представляют собой самый детальный уровень в описании объектов БД оборудования. При описании единицы оборудования используются справочники и реестр систем и позиций, которые ведутся в процессах А1.1 и А1.2, и заполняются следующие реквизиты:

• класс;
• подкласс;
• группа моделей;
• модель;
• название;
• описание;
• инвентарный №;
• заводской №;
• регистрационный №;
• № чертежа;
• дата изготовления;
• дата монтажа;
• гарантия по календарю;
• гарантия по наработке;
• дата гарантии;
• надзорный орган;
• дата проведения последнего ремонта;
• вид последнего ремонта;
• срок эксплуатации;
• вид счетчика;
• наработка.

Ниже перечислены критерии, по которым определяется необходимость занесения записи в реестр оборудования. Для того чтобы запись об объектах попала в БД, она должна удовлетворять критериям:

1. Обязательные критерии:
   • является объектом учета основных средств в бухгалтерии;
   • является объектом технического надзора, имеется отдельный регистрационный номер;
   • отдельное планирование и учет ремонтных заказов;

1. Дополнительные критерии:
   • требуется учет перемещения этого объекта по местам установки и хранения;
   • отдельный учет наработки;
   • отдельный учет технического состояния (дефекты, параметры технического состояния);
   • отдельный учет затрат на объект.

При принятии решения о создании отдельной ЕО или объединении объектов в одну ЕО сначала применяют обязательные критерии и создают список активов, затем по видам оборудования применяют дополнительные критерии и дополняют список активов.

---

Журнал Prostoev.NET № 1(6) 2016
Автор: Алексей Докин, ведущий эксперт по бизнеспроцессам ООО «Простоев.НЕТ»

22 июня, 2022

Работа с НСИ. Как организовать, чтобы сэкономить сотни часов сотрудников

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

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

Отсутствие системности в ведении НСИ может привести к разнообразным проблемам.

Истории из проектной жизни

В справочнике «Статьи расходов» создали свыше 500 разных статей (5 уровней вложенности), для того чтобы получить максимальную детализацию по расходам. Такая детализация существенно затормозила ввод первичной документации, так как сотрудники бухгалтерии постоянно обращались к финансовому отделу за пояснениями, какую статью в каком случае выбирать. К слову, такую отчетность анализировать тоже оказалось неудобно.

Еще одна история про справочник «Статьи расходов»

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

И третья история

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

Крайне важно правильно спроектировать структуру НСИ перед запуском новой системы и не оставлять принятие решений о ее настройках на совести команды внедрения.

Что делать, чтобы избежать ошибок при ведении справочников НСИ?

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

Для начала определим перечень задач, которые необходимо решить:

1. Определить эксперта на стороне бизнеса, который будет принимать решения по реорганизации справочника «Номенклатура», замотивировать и заинтересовать его на работу;
2. Выявить потребности, желания бизнеса в организации структуры справочника;
3. Продемонстрировать эксперту все возможности внедряемой системы в части настройки номенклатуры;
4. Определить и согласовать перечень настроек (шаблоны наименования характеристик, серий, используемые классификации), которые будут использоваться в новой учетной системе;
5. Проанализировать текущий справочник на предмет дублирующих друг друга элементов (как по смыслу, так и по наименованию), неиспользуемых элементов и т.д., для того чтобы определить перечень номенклатуры для переноса в новую систему;
6. Определить правила переноса остатков с учетом схолпнутых дублей, измененных наименований, то есть как сопоставлять «старую» и «новую» номенклатуру» для сверки остатков.

Когда начинать решать эти вопросы?

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

Но не всегда этот вариант применим.

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

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

На что обратить внимание при планировании структуры справочника?

1. Для начала изучить возможность новой системы, что и как в ней можно настроить, на что это влияет, как с этим работать.

Например, 1С:ERP предлагает широкий набор различных классификаций для целей бизнеса:

• Виды номенклатуры – классификатор, предназначенный для объединения номенклатуры по общим признакам учета. Номенклатура одного вида описывается одним и тем же набором свойств.
• Единица хранения – единица измерения, в которой ведется учет складских остатков по данной номенклатурной позиции.
• Качество – градация качества номенклатурной позиции (Новый, Ограничено годен, Не годен).
• Ценовые группы – объединение номенклатуры в группы, для которых применяются одинаковые правила расчета цены и скидок;
• Сегменты номенклатуры – классификация для ограничения области действия соглашения с клиентами, применения скидок;
• Сезонная группа – группа, по которым можно указать коэффициенты сезонности, используемые при планировании продаж и закупок;
• Товарная категория — управление ассортиментом, используется для ассортиментного планирования (укрупненного планирование продаж в разрезе товарных категорий в разрезе форматов магазинов);
• Группы складского учета – классификация с точки зрения физических параметров и принципов размещения и хранения на адресном складе;
• Группы финансового учета – классификация для описания правил отражения операций в регламентированном учете, т.е. позволяет объединить номенклатуру в разрезе бухгалтерских счетов. В рамках группы финансового учета порядок отражения можно настраивать отдельно по организациям и складам;
• Группы аналитического учета номенклатуры – экономическая классификация по однородным группам в целях учета производственных затрат и формирования отчетности, является одной из аналитик для анализа себестоимости продукции;
• Группы доступа номенклатуры – классификация для ограничения доступа на добавление и изменение номенклатуры.

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

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

4. Запланировать сроки выполнения работы. Большая часть должна быть выполнена бизнес-экспертом и важно распределить работы так, чтобы у него оставалось время на выполнение своих прямых обязанностей.

Истории ошибок из проектной жизни для устрашения

На предприятии ведется серийный учет сырья и готовой продукции. При настройке политики серий был выбран тип политики «учет себестоимости по сериям», но для объемов производства – такая детализация себестоимости оказалась излишней. Сам расчет занял продолжительное время. Анализировать такие данные также оказалось неудобно.

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

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

Какие управленческие решения принять, чтобы организовать процесс?

Имея за плечами опыт большого количества внедрений, рекомендую правильно организовать процесс управления номенклатурой:

1. Предприятие выделяет специалистаподразделение (назовем «МДМ-подразделение»), ответственное за управление номенклатурой (НСИ). Специалистподразделение обучены работе 1С в части тонкостей настроек номенклатуры (НСИ).
2. Предприятие разрабатывает регламент заведения нового элемента справочников. Определяет круг лиц, который согласует необходимость заведения элемента. Устанавливает сроки согласования и сроки заведения. Например, за создание нового подразделения отвечает финансовая служба, а согласование нового элемента номенклатуры может быть разделено на разных экспертов в зависимости от назначения самой номенклатуры и ее использования (хозяйственные нужды; тара; материалы, используемые в производстве).
3. Предприятие внедряет и использует отдельную МДМ-систему (о ней можно прочитать ниже по тексту), в которой ведется вся НСИ.
4. Сотрудники предприятия знают о существующем регламенте и следуют ему.
5. Права доступа на добавлениеизменение НСИ ограничены у всех, кроме ответственного сотрудникаподразделения.

Плюсы такого подхода очевидны:

• Существует отлаженный процесс управления номенклатурой на предприятии;
• Бизнес-эксперты заинтересованы в качественной и проработанной структуре номенклатуры в новой системе;
• Понимание потребностей бизнеса в организации структуры справочника;
• Отсутствие или минимальное количество «мусора» в исторической системе;
• Гибкость для изменений как со стороны бизнеса, так и со стороны функционала 1С.

Минусов такой подход практически не имеет, отметила бы:

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

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

1. Настроить проверки уникальности при создании новой номенклатуры, характеристик и т.д.;
2. Ограничить права доступа на созданиеизменение элементов справочника;
3. Выделить владельца(-ев) справочника. Например, бухгалтера, начальника склада и начальника производства, которые будут заводить самостоятельно нужную им номенклатуру.

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

• Количество различных учетных систем на предприятии и их особенности (настроенные обмены независимые базы сбор консолидированной отчетности из всех баз). Для небольших предприятий вариант с выделением МДС-подразделения будет неактуален.
• Временной лаг между возникновение потребности в создании нового элемента и его создание в системе, порой весьма значительный.
• Размеры самого справочника «Номенклатура», если в нем немного позиций, то выделение МДМ-подразделения будет не актуально.
• Размеры предприятия (количество юридических лиц и их особенности), для штата в 10 человек выделение МДМ-подразделения не актуально.

Примеры организации учета НСИ

Делюсь рекомендациями на примерах из практики.

Пример 1.

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

Решение:

• Одну из новыхисторических учетных систем принять за центральную для ввода номенклатуры;
• В остальных системах справочник «Номенклатура» заблокировать для ручного ввода новых элементовизменению старых;
• Новые элементы вводить только в центральной системе, в остальные транслировать при помощи обмена.

Плюсы решения:

• Сопоставимость отчетности между системами;
• Отсутствие дублирующих элементов во всех системах;
• Единая номенклатура для всех систем;
• Сокращение времени на исправление допущенных ошибок (человеческий фактор не исключаем).

Что рекомендую: обратить внимание на следующие нюансы использования такого решения, которые могут затруднить работу:

• Дополнительные трудозатраты для разработки правил обмена центральной системы с остальными;
• Не гибкий подход — при любых изменениях потребуется доработка обмена;
• Отсутствие ручного управления, что происходит при обмене – «черный ящик» для пользователя;
• При возникновении ошибок обмена, пользователь в 99% случаях не сможет самостоятельно решить проблему, потребуется помощь службы поддержки.

Пример 2.

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

Решение: Использовать отдельную МДМ-систему.

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

Плюсы использования МДМ-системы:

• Гибкий подход в ведении номенклатуры. Система МДМ позволяет выбрать различные варианты точек ввода НСИ:

• • централизованный (ввод в МДМ и транслирование в другие базы);
  • децентрализованный (ввод НСИ в системах учета, трансляция в систему МДМ, в которой элементы разных баз будут сопоставлены между собой и по заданным параметрам соотнесены как различные вариации одного элемента);
  • гибридный (соединение централизованного и децентрализованного ввода).

• В системах МДМ может быть уже преднастроенный обмен с другими учетными системами, что значительно облегчит ее внедрение и уменьшит трудозатраты на доработки;
• Настройка различных группировок, классификаций внутри системы МДМ (без доработок учетных систем) для дальнейшего использования в отчетности;
• Построение консолидированной отчетности на основе данных НСИ из МДМ-системы, например, BI-отчетности;
• Использование МДМ-системы подразумевает выделение ответственного сотрудникаподразделение, которое будет отвечать за процессы, регламенты, стандартизацию НСИ, а значит единый подход;
• Сокращение времени на исправление допущенных ошибок.

Что рекомендую: обратить внимание на следующие нюансы при выборе это подхода:

• У некоторых МДМ-систем закрытый код, что означает невозможность самостоятельной доработки под нужды предприятия, как следствие увеличение затрат на доработку системы, так как необходимо привлекать компанию-разработчика решения;
• Из предыдущего пункта также следует то, что поддержкой такой МДМ-системы может заниматься только компания-разработчик – это увеличение затрат;
• МДМ-система – это отдельный проект, с отдельным бюджетом и командой внедрения;

Выводы

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

Успехов во внедрении!

Оригинал статьи размещен на портале Клерк.ру