«Корпоративная автоматизированная система управления бизнес-процессами Материально-технического и транспортного обеспечения в бурение» (стр. 5 )

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

АСУ МТО должен самостоятельно выстраивать маршрут согласования в зависимости от параметров данных, например, приоритет или сумма, и определять заинтересованных ответственных сотрудников.

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

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

·  ФИО, должность инициатора потребности;

·  ФИО, должность согласующего;

·  Решение согласующего (Утверждено/Отклонено);

·  Комментарии согласующего;

·  Дата и время выполнения согласования (по каждому согласующему).

Оповещение согласующего подразумевает рассылку электронных оповещений на почту сотрудника, с указанием:

·  Данных (объекта задачи);

·  Параметров потребностей;

·  Web-ссылка для входа в Систему и открытия задачи на согласование.

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

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

·  Последовательный;

·  Параллельный.

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

·  В случае положительной визы согласующего, данные переходят к следующему согласующему;

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

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

·  В случае положительной визы всех согласующих, либо одного из согласующих, данные переходят на следующий этап согласования.

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

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

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

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

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

·  либо утвердить дополнительный лимит затрат;

·  либо определить потребность как аварийную.

Согласование аварийных потребностей:

Аварийные потребности должны проходить согласование:

·  Либо по очень сокращенному маршруту;

·  Либо уже по факту их исполнения.

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

4.2.7.  Обеспечение потребностей (Часть процесса управление запасами).

1.   

2.   

4.2.7.1.  Анализ складских запасов.

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

·  Определять источники пополнения запасов;

·  Анализировать возможные аналоги номенклатуры;

·  Анализировать страховой запасы;

·  Просматривать складские остатки в разрезе складов и организаций.

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

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

·  Номенклатура;

·  Склад;

·  Количество;

·  Количество для дозаказа.

В обработке «Ввод и согласование потребностей» должна быть возможность с помощью кнопки «Заполнить под страховой запас» автоматически создать оперативные потребности. Далее провести процедуру согласования данных потребностей. Аналитика по потребности заполняется по параметрам пользователя, определенным для подстановки, либо до заполняется вручную. При согласовании данной потребности должен быть виден реквизит данной потребности «Для пополнения минимального страхового запаса». Страховой запас должен определяться на «Центральный склад».

4.2.7.2.  Определение способа обеспечения потребностей

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

·  По параметрам планирования;

·  По способу закупки (централизованной, самостоятельной);

·  В разрезе организаций;

·  В разрезе ЦФО;

·  В разрезе складов;

·  В разрезе приоритетов (текущие, срочные, аварийные).

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

Механизм обеспечения потребностей должен:

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

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

o За счет свободных остатков;

o За счет перемещения;

o За счет закупа.

Механизм обеспечения оперативных потребностей должен выводить:

·  Требуемую дату исполнения потребностей, рассчитывается из потребности;

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

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

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

·  Остатки;

·  Перемещение;

·  Закупка.

Система должна контролировать количество обеспечиваемой потребности и блокировать действия пользователей при:

·  Закупке большего количества, чем в потребности, с учетом уже закупаемого;

·  Перемещение большего количества, чем в потребности, с учетом уже перемещенного;

·  Списание большего количества, чем в потребности, с учетом уже списанного.

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

·  Склад получатель;

·  Склад отправитель.

Использование «складов исключений» не допустит обеспечение потребностей Бригады А за счет свободных остатков Бригады Б, которые на текущий момент могут быть уже списаны но не отражены в Системе. В случае когда, потребуется обеспечения потребностей Бригады А за счет свободных остатков Бригады Б, необходимо установить флаг «не использовать склады исключения». Данный перечень заполняется/редактируется ответственными пользователями вручную.

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

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

В Системе реализовать механизм определения и хранения номенклатуры в рамках Перечня №1, Перечня №2, Перечня №3. Данные перечни впоследствии будут использоваться как отборы для:

·  Централизованной закупки (Перечень №1);

·  Самостоятельной закупки (Перечень №2);

·  Самостоятельной закупки (Перечень №3).

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

4.2.8.  Выбор поставщика номенклатуры

1.   

4.2.8.1.  Подготовка запроса поставщика

В АСУ МТО. TMS для подготовки запроса поставщикам использовать документ «Заявка на закупку». Пользователи при создании документа могут определять следующие параметры:

·  Способ оценки предложений;