Перед тем как описать алгоритм работы на "уровне операций", рассмотрим в общих чертах, что он из себя представляет.
В главе 2.2 Знакомство с архитектурой HubCloud.io мы познакомились с идеей, что в учете всегда есть Списки и Операции. Списки - это, что мы учитываем. Операции - это действия (или события) над элементами из этих Списков. Списки мы настроили на уровне ER-модели (или на "уровне справочников"). А Операции мы настроим на этом уровне.
Вторая идея в следующем. Один из вопросов автоматизации: "каким образом информация окажется в учетной системе"? Даже если информация вносится в автоматическом режиме, например, при помощи сканеров, даже в этом случае для каждого сотрудника действует следующая схема: "сделай такое-то действие и отрази завершение этого действия. На бумажном ли носителе или в информационной системе - это не важно". Важно, что всегда есть какая-то отметка об исполнении.
Например: "Принял товар на склад - отметь в журнале (или в информационной системе)". Или: "Выдал заработную плату сотруднику - отметь в журнале (или в информационной системе)". И так далее.
Другими словами, на "уровне операций" (в числе прочих задач), решается и организационный вопрос, "кто-когда-какую" информацию внесет в систему. Очевидно, что без этого автоматизация не возможна.
Третья идея в том, что практически все расчеты в системе происходят на "уровне операций". Соответственно на этом уровне нужно понять, какие расчеты необходимы в данном конкретном учете.
Инструментом "ER-модели", эти задачи решить нельзя. Продемонстрировать это легче на примере.
Пусть наш пример - это "складская торговля". Для чистоты эксперимента нужно представить, что мы абсолютно ничего не знаем об этом виде деятельности.
Представьте, что вы инопланетянин, с планеты на которой уже 1 000 000 лет нет торговли и производства в нашем смысле. Есть некие устройства, которые любую мысль преобразуют в нужную вещь. Доступ к таким устройствам не ограничен, и нет потребности создавать компании, склады, производство, юридические лица и прочее.
Соответственно, у нас нет абсолютно никакого представления в целом о процессе торговли и о ее составляющих, таких как Заказ, Резерв, Клиент, Менеджер, Счет, Оплата и так далее.
Вы встретились с заказчиком и создали схему ER-модели. (См. рисунок ниже).
Центральным местом в схеме будет "Товар". Он связан с Поставкой, Резервом, Заказом, Отгрузкой и Складом.
Теперь "забежим вперед". Даже если вы не сталивались с учетом торговой компании, то можете предположить, что "бизнес-процессах" торговой компании могут происходить следующие действия и события:
- приход товара от поставщика
- возврат товара поставщику (в случае брака)
- назначение цены продажи и скидок
- постановка в резерв
- отмена резерва
- отгрузка товара клиенту
- возврат товара от клиента
- инвентаризация товара
- корректировка пересортицы
- корректировка недостачи и избытков
- списание испорченного товара
- проверка поступления оплаты от клиента
- контроль остатков на складе
- прогнозирование продаж
- закупка товара исходя из остатков на складе и прогноза продаж
- расчет прибыли от торговых операций
(!) Этот список не полный, и возможно для некоторых компаний избыточный, но для некой усредненной компании B2B - это типичные действия в ее "бизнес-процессах".
Вернемся к нашему примеру с "торговлей и инопланетянином". Если вы совсем не знакомы с деятельностью торговых компаний, то глядя на ER-модель вы никогда не догадаетесь о таких процессах, как назначение цены, устранение пересортицы, контроль остатков и прочих действиях и событиях. Приведем полный список событий и действий, наличие которых сложно "увидеть" из ER-модели. Это пункты: 3, 8, 9, 10, 11, 12, 13, 14, 16.
Проведите мысленный эксперимент. Попробуйте "увидеть" каждый из этих пунктов в ER-модели. Иногда вы поймете, что вы просто не отразили какую-то сущность. Например, пункт 3 (назначение цены продажи и скидок). Возможно, что на схеме пропустили такую Сущность, как "Прайс". Тогда можно сказать, что это ошибка "интервьюера".
Но иногда, например в пунктах 9 (корректировка пересортицы) и в 16 (расчет прибыли торговых операций) даже при всем желании в схеме ER-модели это нельзя "увидеть" и отобразить.
То есть инструмент "ER-модель" не совсем подходит для работы на этом уровне. При этом ER-модель позволила первично познакомиться с Сущностями и создать все справочники в системе.
Переходим к рассмотрению следующего уровня.
“Уровень операций” менее "технологичный", чем уровень "ER-модели (или "уровень справочников")".
На "уровне справочников" мы построили ER-модель, следуя алгоритму:
- задать вопросы: "что у вас есть в учете"? (определили сущности)
- задать вопросы: "как это связано" (определили тип связи: 1:1, 1:n, n:n)
- задали вопрос "об обязательности" (определили кардинальность связи: 00, 0I, II)?
- по алгоритмам "таблицы-шпаргалки" перешли от ER-модели к "таблицам"
- создали справочники в системе
На уровне операций можно предложить схожий алгоритм (в этой главе ниже), но его исполнение не будет таким однозначным, как на "уровне ER-модели". В нем будет на порядок больше неопределенности. Причина в том, что "учет и бизнес-процессы"- очень разнообразны и из-за своего разнообразия не имеют единого решения. И когда мы поднимаемся от "скелета" дальше, то уровень этого разнообразия (и неопределенности) проявляется сильнее.
Продемонстрировать это легче на примере. В "торговых компаниях B2B" есть процесс проверки оплаты от клиента". Так как склад может находится в одном месте, а сотрудник бухгалтерии в другом, то должна быть какая-то процедура, когда сотрудник склада может удостовериться, что клиент оплатил деньги и ему можно отдать его товар.
Нет ничего проще, чем в настроить в системе при отгрузке товара проверку на осуществление оплаты, какой-то признак оплачено, который устанавливается автоматически если в системе есть "платежка" от данного клиента.
Но давайте продемонстрируем, насколько такая типовая процедура может отличаться в разных компаниях, в зависимости от разных условий:
1) По бизнес-процессу компании бухгалтер вносит в системе платежи раз в день с утра. А деньги от контрагента могут придти в обед, и все участники процесса и менеджер по продажам и снабженец у клиента знают, что это произошло, и оба хотят осуществить отгрузку. Но в системе денег еще нет, бухгалтер их внесет в систему завтра.
2) "особые покупатели". Это клиенты, которые работают вместе десятки лет, или собственники которых хорошо знакомы. То есть такие отгрузки проходят без процедуры контроля
3) на рынке могут быть приняты условия "продажи в кредит", но для тех компаний, которые прошли определенную процедуру проверки. Для каждой компании может быть установлен лимит в сумме задолженности. Ну то есть на 100 рублей отгрузить можно, а на 101-й рубль уже нет.
4) лимит может быть не в сумме, а в сроке. Или внутри месяца можно отгружать безлимитно, но но если задолженность от любой отгрузки больше 1 месяца хотя бы на рубль, то отгрузка останавливается
5) Кредитные лимиты могут действовать только прохождения внутреннего совещания, и могут действовать ограниченный срок, после чего вновь должны пройти через внутреннюю процедуру. То есть в системе должна быть проверка этих условий
6) Дополнительно могут быть назначены "ковенанты" - условия выполнение/не выполнение которых может влиять на кредитный лимит. Например если клиент купил в прошлом месяце менее чем на 100 рублей, то в следующем кредитный лимит "слетает". Ковенантой может быть предоставление клиентом какой-то информации.
На практике таких условий может быть еще больше и они могут быть еще сложнее. Возможно, что их вообще может быть бесконечное количество. И это только по одному процессу.
(!) Если вы думаете, что "бесконечность" громкое слово, то подумайте о том, что этими 6-ти вариантами условий ситуация не ограничивается. Например:
7) Компания может работать на двух продуктовых рынках с абсолютно разными "рыночными" графиками оплаты. И в одном случае отгружать всем только по предоплате за полгода вперед, а в другом рынке давать отсрочку платежа на полгода.
8) Компания определила лимиты на отгрузку в кредит и перечень сотрудников, кто может принять такое решение. Например, начальник отдела продаж филиала под свою ответственность может отгрузить на 1 млн. рублей, а директор филиала на 5 млн.
А теперь представьте, какое количество вариантов можно скомбинировать из этих восьми условий?
P.S. 9) цена зависит от условий оплаты: «15 дней до поставки –5% от цены», «15 дней после поставки +5% к цене»
Такое разнообразие приводит к тому, что учет каждой компании становится уникальным, а также к тому, что появляются различные способы реализации. То есть этот уровень "не технологичный", ситуация одна и та же, а способов реализации - много. Однозначных критериев выбора способа реализации - нет.
Последовательность работы на этом уровне можно разделить на пять этапов:
- определяется перечень Операций, которые будут в системе
- определяется вид Операций, а также перечень и расположение в них Полей
- настраиваются сервисные функции Операции (для удобства работы пользователей или для ограничения возможности совершения ими ошибок)
- настраиваются все расчеты (80% расчетов реализовываются на этом уровне)
- настраивается проведение Операций в Журналах
На этапе 1,2,3 заказчик может оказать вам большую помощь в работе. Это единственный уровень, на котором заказчик может полноценно участвовать в проекте (на других уровнях из-за недостатка знаний заказчик полноценно участвовать не сможет). Если вы сумеете вовлечь его в процесс, то заказчик по-настоящему компетентно может выполнить до 80% работы на этапах 1,2,3. После чего вы сможете завершить работу на этапе 4 и 5.
Как вовлечь сотрудников заказчика в процесс работы?
Начать нужно с того, что каждому сотруднику, участвующим в учете следует задать вопрос: “какие операции вы совершаете на вашем рабочем месте”? Ответить на этот вопрос сотрудники могут ответить практически всегда. И даже сразу попросить помощи в автоматизации тех или иных расчетов.
Давайте приведем несколько примеров, чтобы можно было просто почувствовать как это выглядит. Сотрудники заказчика могут сказать что-то примерно такое:
- “формирую список платежей на неделю”.
- “отмечаю в файле инвойсы, которые пришли в порт”
- “считаю премию менеджерам”
- “уточняю у поставщиков, готовы ли наши заказы и распределяю, кто из курьеров заберет какой заказ”
- “на основании статистики и остатков на складе, делаю ежемесячный заказ поставщику”
- “назначаю цену товара в зависимости от цен конкурентов”
- “определяю очередность производства заказов”
- “делаю вручную вот такой отчет”
- “из заявок филиалов составляю единую заявку на закупку”
- “контролирую, чтобы поставщики доставляли товар не позднее 3-х дней после нашей им оплаты
После того, как у вас есть перечень действий сотрудников, можно составить перечень Операций. Иногда несколько действий сотрудников могут стать одной Операцией в системе, и наоборот, одно действие может быть стать несколькими Операциями. Здесь и начинается неопределенность. И выработать алгоритм сложно.
Например, в нашем примере контроля проведения оплаты, в какой момент времени (в какой Операции), осуществлять эту проверку? В Операции "Заказ покупателя" или в Операции"Отгрузка товара"? Для тех клиентов, кто попадает под "отгрузку в кредит" – удобно проверять в "Заказ покупателя", так как мы заранее уже знаем, что разрешим отгрузку.
Но для тех, кому не разрешена "отгрузка в кредит", то проверять нужно в "Отгрузке товара" так как Заказ делается задолго раньше (за 5 дн. например), чем Оплата (за 1 дн, например).
Возможно, что нужна будет третья Операция "Разрешение на отгрузку", в котором и будет происходить это сложное вычисление различных условий. А возможно, что это станет понятно тогда, когда настройка системы уже завершена.
Можно сказать, что создание учетной системы - типичное проектирование. Создали вариант, через несколько шагов поняли, что он ошибочен, вернулись – переделали. Сама настройка Операций не трудоемка и занимает 3-5 минут на одну Операцию.
(!) Кстати, это принципиальное отличие системы HubCloud от любых других. Трудоемкость разработки сведена к 0. К сожалению, трудоемкость проектирования в данной области к 0 свести не возможно.
(!) В отличии от “уровня проводок” на “уровне операций” специального инструмента (как ER-модель) не требуется. Моделирование происходит прямо в системе HubCloud.ru , то есть сама система и является инструментом моделирования.
Вы можете предположить, какие Сущности могут быть в операции и можете поместить их в Шаблон Операций. Далее можно встретиться с заказчиком, и продемонстрировать ему эти Шаблоны. Для того чтобы заказчик включился в процесс корректировки Операций требуется, чтобы с первых шагов заказчик видел только “свои привычные” названия. Это очень важно.
(!) Дело в том, что в момент “знакомства с новым” происходит переизбыток информации, от чего канал восприятия сильно сужается. Поэтому, чем больше знакомой информации увидит сотрудник заказчика, тем легче ему будет представить, как должна выглядеть Операция.
Поэтому 1) старайтесь всему давать такие названия, к которым привык Заказчик. К этому моменту у вас есть Справочники заказчика (после ER-модели). Для каждого справочника спросите один два примера.
2) когда будете работать с операцией сразу называйте поля так, как привычно заказчику.
После того, как операция обрет “узнаваемые названия”, когда в поля операции можно выбрать знакомые для него названия, то заказчик активно включится в работу по изменению Операции.
Подведем итоги главы: мы познакомились с “уровнем операций”. Мы говорили о том, что этот уровень "не технологичен", что работа на этом уровне представляет собой проектирование, то есть высокая доля неопределенности при начале работ, редактирования уже созданных и настроенных Операций. Также мы обсуждали возможность подключения сотрудников заказчика к работе на данном уровне.
В следующей главе познакомимся, что из себя представляет Операция.