Регламент управления торговлей для 1С УТ 8

Предлагаю вниманию нашу версию инструкций для 1С Предприятие.

Эта инструкция с заваленного проекта. Точнее он был завален, а далее мы его взяли на буксир в соответствии вот с этими правилами 4 ключевые проблемы проектов внедрения 1С Предприятие.

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

Особенности инструкции

1. Под словом инструкция, у нас понимается описание процесса, от описания порядка действий, до закрепления определенных правил. Или в перемешку. Зависит от ситуации.

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

3. Инструкции содержащие правила, мы называем Инструкции, Правила, Кодекс, Политика, в зависимости от контекста и удобства.

Принципипальное отличие

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

Т.е. мы вместо объекта, например "справочник Номенклатура", берем функции, например "Поступление товара", в котором прописываем порядо действий, в т.ч. со справочником Номенклатура.

Правила разработки инструкций

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

2. Декомпозиция процесса

Это сложное понятие. Нужно поднимать учебники чтобы его вспомнить дословно. Но попробую своими словами. Но словами это знание плохо передается. Чтобы реально понять что это такое, нужно пару моделек написать самому. Вот тут есть хороший тренажер http://businessstudio.ru/, я на нем учился. Сейчас могу уже и в голом Word'е писать, т.к. понял основы.

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

б) Что такоп Процесс, Процедура и Функция мне объяснить сложно, т.к. я могу придумать много слов и один фиг толку от них будет мало. Лучше обратиться к учебникам на сайте http://businessstudio.ru/.

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

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

3. Пример декомпозиции процесса.

Разберем пример из вложенной инструкции.

Как мы ее получили?

Очень просто.

Берем чистый лист бумаги Word.

Настраиваем стиль так чтобы заголовки имели список вида А1.1.1. Заголовок третьего уровня

Это нужно для описания процессов и процедур (иногда функций)

Далее задаем себе вопрос. Как звать процесс? Отвечаем: процесс звать Управление торговлей.

Если бы мы описывали процесс предприятия в целом, то он бы получил индекс А1. Управление торговлей. Но т.к. этот процесс является основной инструкции, то он получает индекс А0. И просто записывается в название. Это наше правило. Если говорить о BS, то там он записывается как А0.

Далее задаем себе вопрос, из каких пунктов он состоит? Для декомпозиции хорошо подходит вот эта методика от McKinsey Будьте ВИСИ

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

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

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

Если декомпозировать Опт, то задаем вопрос, на какие действия он делится?

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

Ограничения

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

Вывод

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

P.S. Если говорить о конфликте с German, который возник Тут, то его суть заключается в том, что действие под названием "Добавить новый товар" для справочника Номенклатура в рамка процесса управление торговлей, отличается от действия "Добавить материал" в рамках процесса управления производством. И правильный подход, это описывать действия. Если описывать объекты программы аля "что можно наделать со справочником Номенклатура" то пользователю от этого описания не тепло не холодно. Он просто не понимает нафига ему читать эту лабуду. Она нужна программисту чтобы понимать поведение объектов системы и их алгоритмов. А пользователю эти подробности ни в одно место не упирались.

(с) Группа "Инструкции и регламенты для 1С Предприятие"