Экспресс-обследование и реинжиниринг бизнес-процессов

Я расскажу, как я делаю обследование компаний, которые хотят внедрить учет для целей управления – «а-ля» МСФО. Такой управленческий учет можно организовать в конфигурациях 1С, имеющих подсистему международного учета – это УПП, ERP, УХ, ERP УХ, БП КОРП МСФО.

Для начала представлюсь – меня зовут Николай Шилкин, я уже четверть века занимаюсь внедрением программных продуктов управленческого и международного учета, в частности, занимаюсь автоматизацией МСФО. Здесь на слайде представлены некоторые этапы моей профессиональной деятельности.

Прошу обратить внимание на девиз «Облегчим жизнь бухгалтеру» в самом низу слайда. Он родился в начале моей карьеры, когда мы внедряли US GAAP в одной американской компании, и там аудиторы KPMG из Великобритании у меня спросили: «Почему у вас в России бухгалтерами и аудиторами работают, в основном, женщины? У нас в Великобритании считается, что это тяжелый труд, работают только мужчины». Я тогда пошутил: «Мы вообще в России наших женщин любим и поручаем им самую ответственную работу, например, строить железные дороги, таскать на них рельсы и шпалы...» Представители KPMG оторопели, спрашивают: «It’s a joke?» (Это шутка?) Я говорю: «Да, шутка». Но, на самом деле, шутка получилась грустная, и с тех пор у меня родился этот девиз. А поскольку бухгалтерами у нас, в основном, работают женщины, я стараюсь максимально облегчить им жизнь, чтобы, сделав проект, они уже не возвращались ко всяким доделкам и переделкам.

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

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

Терминология

Несколько слов о терминологии.

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

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

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

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

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

Теперь давайте разберем термин «Параллельный учет».

В данном случае речь идет о параллельном бухгалтерском и управленческом учете, который, как правило, внедряется на конфигурациях, имеющих подсистему международного учета – это УПП, ERP, УХ, ERP УХ, БП КОРП МСФО.

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

• Такой параллелизм возможен, если стандарты схожи.

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

• Ну и плюс для управленческих целей – если, опять-таки, управленческий учет строится «а-ля» МСФО, используются некие оценочные суждения, которые, как правило, отрабатываются ручными операциями.

Соответственно, возникает три таких «куска»:

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

• второй «кусок» – это то, что мы не можем запараллелить, но можем частично автоматизировать какими-то регламентными операциями (классический пример – амортизация);

• ручные операции.

Последовательность внедрения управленческого учета «а-ля» МСФО

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

• Сначала нужно изучить те методологические моменты, которые есть у заказчика.

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

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

• Мэппинг счетов БУ и УУ для параллельного учета.

• Дальше, при необходимости, разработка тех документов, которые не предназначены для параллельного учета. Еще раз обращаю внимание, что терминология 1С-ников называет «параллельным учетом» независимый учет, что, в общем-то, для меня странно – я этим занимаюсь четверть века, а в 1С такой термин появился только в последние 10 лет.

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

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

Виды и цели обследований

Согласно моей практике, обследование делится на:

• предпроектное обследование;

• то обследование, которое уже можно назвать аудированием (ИТ-аудит) – оно проводится либо внутри компании, либо приглашается сторонний эксперт.

На этапе предпроектного обследования обычно производится:

• Анализ информации о корпоративных стандартах компании;

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

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

• Проводится интервью, чтобы:

  • Понять, как от того, что есть, перейти к тому, что будет на новом софте;

  • Проанализировать, как люди работают сейчас, и где именно можно облегчить им жизнь;

  • Выстроить шкалу приоритетов, расшивая самые трудоемкие места в первую очередь.

По поводу ИТ-аудита я уже рассказал – вы можете еще раз прочитать это на слайде:

Гармонизация бухгалтерского и управленческого учета

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

Каким образом это происходит? Анализируются две учетных политики: управленческая и бухгалтерская (кстати, в бухгалтерскую часто включается еще и налоговая учетная политика), и дальше смотрится, можем ли мы их как-то сблизить.

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

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

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

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

• Например, вариант обогащения часто возникает, когда мы делаем расчеты intercompany. Если учет достаточно простой: есть «внутригрупповые» компании, и считается, что они входят в Группу, а все остальные в Группу не входят, то это бифуркационная модель, где можно обойтись каким-то «флажком».

• А если управленческий учет близок к международному, и, как основа, используется стандарт МСФО 24, который гласит, что есть материнские, дочерние, ассоциированные, связанные предприятия, тогда это уже не две градации, а гораздо больше. И приходится расщеплять уже не просто «флажком», а делать специальный справочник или перечисление, – в зависимости от того, как бизнес-аналитики договорятся и согласуют эти параметры, – чтобы можно было делать более серьезное расщепление, позволяющее рассматривать отчетность уже в разрезе этих классов компаний.

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

Проведение обследования – анализ корпоративных стандартов УУ

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

Анализ организационной структуры подразумевает определение центров финансовой ответственности – я привел на слайде самые часто встречающиеся, например:

• «Продуктовые линейки» (Product Lines) можно спроецировать на справочник 1С «Номенклатурные группы»;

• «Функции» (Functions) – если мы говорим о структуре данных 1С, это ни что иное, как подразделения группы – то, что в УПП называется просто «Подразделения»;

• «Локации» (Locations) – места осуществления продаж для анализа продаж – справочник «Регионы»;

• «Проекты» (Projects).

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

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

• Могут дробиться иерархически. Т.е. регион EMEA (Европа, Ближний Восток) дальше делится по странам, страны делятся по какому-то внутреннему административному делению, следующая градация – города и т.д.

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

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

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

Как расшифровывается MECE? Это английская аббревиатура Mutually Exclusive & Collectively Exhaustive. По-русски это означает «Взаимно исключающие и совместно исчерпывающие» или аббревиатура «ВИСИ». В общем, звучит страшно.

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

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

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

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

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

Этап проектирования – реинжиниринг бизнес-процессов

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

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

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

Эта эффективность, как правило, измеряется такими параметрами, как маржинальность, захват рынка и т.д. – у всех свои метрики.

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

С последовательностью реинжиниринга бизнес-процессов (РБП) все более-менее понятно:

• Сначала процессы нужно выделить и идентифицировать;

• Потом описать “as is” и “to be”;

• Далее – внедрить.

Для графического представления бизнес-процессов можно использовать различные нотации: IDEF, eEPC, BPMN 2.0, UML и ДРАКОН.

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

Обращаю внимание, что наряду с зарубежными нотациями есть отечественная нотация – ДРАКОН, с помощью которой разрабатывался космический корабль «Буран». В сообществе Инфостарта есть 1С-ники, которые работают с этой нотацией. Самое интересное, что ДРАКОН – это аббревиатура, я ее чуть позже расшифрую.

По поводу разработки ТЗ – тут такая же ситуация.

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

• Если же вы считаете, что вы сделаете проект «на ура», ТЗ можно не разрабатывать.

У меня, как правило, второй случай – за все время я всего два раза писал ТЗ, и, к сожалению, оба раза они не были использованы. Один раз, потому что клиент перешел на другую систему, а второй раз – просто потому, что поменялось руководство, а «новая метла по-новому метет», и вообще отказались от внедрения. Это были достаточно серьезные конторы, но это – реальные случаи из практики.

Результат обследования и рекомендации

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

Обратите внимание, что здесь выделено слово «Рекомендации». Во-первых, рекомендации нужны, чтобы можно было обозначить клиенту свои компетенции: «Я рекомендую делать так, потому что…». И, во-вторых, рекомендации нужны, чтобы застолбить себе некий фронт работ, который может возникнуть уже после внедрения.

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

Нормализация справочников и разработка регламентов заполнения и содержания

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

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

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

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

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

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

Есть пассивная и активная регуляция:

• Пассивная регуляция – это как светофор: зеленый, желтый, красный свет. Но вы можете проехать на красный свет, и никто вас не остановит.

• Но чем хороша работа автоматизатора? Тем, что вы можете запрограммировать так, что связать машину и светофор таким образом, что на красный свет машина будет останавливаться, а на зеленый – ехать. И в этом плане, когда вы конструируете работу пользователя, вы всегда можете вставлять такие «светофоры» – в частности, для заполнения обязательных реквизитов. Делайте активную регуляцию!

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

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

Такая группировка позволяет пользователю очень легко ориентироваться:

• если мы кому-то платим, то он идет в оттоки;

• если нам платят – он идет в притоки;

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

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

• Про ключевые слова все понятно – это просто машинная сортировка, которая отрабатывает посимвольно. Ключом является вот это первое слово, которое мы используем. Допустим, у вас есть «ПАО Альфа-Банк» или «фирма Альфа» – вы ключевое слово выносите в начало, и тогда все названия контрагентов, которые начинаются на «Альфа», группируются в одном месте и умещаются на одном экране. Пользователь может выбрать ту «Альфу», с которой он сейчас работает.

• Гнездовой метод тоже позволяет сгруппировать на одном экране или на нескольких ближайших экранах по первым символам, но дело в том, что он группировку осуществляет не по ключевым словам, а по каким-то другим критериям. Например, вы хотите, чтобы у вас на одном экране помещались все банки – тогда вы впереди добавляете слово «Банк». И у вас название контрагента уже будет звучать по-другому: Банк «Альфа», Банк «ВТБ», Банк «Сбер». В результате вы получаете некое «гнездо», которое начинается на «Банк». Это иногда очень удобно. Здесь я привел пример с ИП, потому что немногие работают с ИП – обычно ИП-шников в базе 10 или 20, их очень удобно сгруппировать. Вы набираете всего лишь две буквы: «ИП», и компьютер сразу выводит вас на первого ИП-шника, плюс вы видите всех остальных.

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

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

• С другой стороны, регламенты обеспечивают преемственность: когда приходят новые сотрудники, чтобы они могли «с места в карьер» начать работать в той системе, которую они, может быть, даже и не знают. Потому что в компаниях часто бывает, что одни люди уходят, а другие приходят. Это связано не только с увольнениями, но и с больничными, командировками, с декретными отпусками. Когда даже внутри одного департамента сотрудники меняются ролями – в таких временных ситуациях, когда человек отсутствует на рабочем месте и его нужно подменить. Тогда, прочитав регламент, новый пользователь может легко включиться.

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

Глоссарий

Здесь я привожу те англоязычные аббревиатуры, которые использовались в докладе – просто для того, чтобы они не забылись.

А это – то же самое, но для российских сокращений. Обратите внимание, как расшифровывается ДРАКОН – Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность. Видно, что расшифровка подгонялась под название, но, все равно, это реально работающий инструмент. И, кому интересно, на Инфостарте есть ребята, которые используют ДРАКОН применительно к 1С. Это русская система, еще и с таким интересным названием. Это то самое положительное импортозамещение, а не наклейка шильдиков на китайские товары. И в этом, конечно, прелесть этой системы.

Вопросы

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

Да, такое часто на практике встречается. Причем, встречается в двух видах.

• Первое – у пользователей есть внутренние корпоративные регламенты и им нужно соответствовать.

• И второе – это когда люди на местах делают отсебятину. Просто кто-то ошибся или посчитал, что ему так удобнее. Обычно это начинается с того, что не прочитал инструкцию или не прошел обучение, и ему просто никто не сказал, что так делать не надо.

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

А с первым случаем все гораздо сложнее. Допустим, у вас в корпоративных стандартах прописано, что документы «Накладные» мы маркируем такими-то буквенными символами, и начинаем нумерацию, например, с 1000 или с 1000000, и лишь в конце – значащие цифры. Эту разрядную сетку уже надо конструировать. В этом случае я бы советовал не ломать типовой 1С-ный номер, а добавить на форме новое поле, которое генерируется в соответствии с корпоративными стандартами и подставляется в печатную форму или выгружается в электронный документ. Сейчас это делается с помощью расширений.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Бизнес-аналитик. Роль в команде, компетенции, инструментарий".