bpm

Любая задача, с которой к нам обращаются, преследует свою ЦЕЛЬ. Очень важно ее выделить, чтобы во-первых было понятно назначение всей работы и во-вторых чтобы было понятно достигли мы ее или нет.

В формулировании ЦЕЛИ исходите из того, что вы хотите получить в конечном виде.

В целом:

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

Для транспортной компании – отследить расходы на топливо, контролировать исполнение заявок клиентов.

Для юридической фирмы – контроль биллинга счетов.

В частном:

Для конкретных обработок это может быть – упрощение работы с конкретными документами, контроль доступа до информации, автоматизация обмена данными, автоматизация формирования перечня документов, формирование связи документов. Для каждой задачи – своя ЦЕЛЬ.

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

 

В этом Вам поможет следующий небольшой план:

Для каждой функциональной единицы задачи (к примеру – Документом Заказа) необходимо оформить следующие данные:

1. Кто будет работать с функциональной единицей

1.1 Должности сотрудников, использующие данную ФЕ, и их функциональные обязанности

2. Назначение программы

2.1. Функции, которые должна выполнять программа, например:
2.1.1 хранить справочник
2.1.2. формировать документ
2.1.3. составлять отчет и пр..

2.2. Описание

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

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

2.2.3 Нужно указать какая ФЕ с какими данными работает, источник этих данных

2.3. Интерфейс пользователя

2.3.1. Интерфейс взаимодействия пользователя с программой. Схема работы программы, где какая кнопка должна быть.

2.4. Какие данные будут храниться в программе

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

2.5. Необходимые расчеты

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

2.6. Отчеты

2.6.1. Какие отчеты должна предоставлять программа. В каком виде (предоставить шапку отчета, требуемые группировки данных). Если есть расчетные данные, предоставить формулы расчета.

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

 

Для образца приведем общий, лаконичный, пример:

Документ Заказ на поставку

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

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

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

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

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

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

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

Также заказ может быть отменен (по инициативе поставщика или заказчика) с указанием причины отмены. Информация об отмене должна так же поступать в виде уведомления начальнику подразделения.

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

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

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

 

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