Должен ли аналитик знать проводки и учить бухгалтера выстраивать регламентированный учет?

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

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

Но в проектах автоматизации производственных процессов в 1С:ERP, избыточная фокусировка на проводках только вредит – как аналитику, так и всей команде.

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

Получается, что, зная проводки, мы знаем в процессе только две последние операции. А то, что до них – еще 15, 30, 40 важных шагов, которые существенно влияют на результат автоматизации – мы не знаем.

Чтобы эти шаги понимать – как раз и будем говорить про технологию системного подхода.

Расскажу немного о себе. Я работаю с 1С достаточно давно, с 1996 года. Очень многое в проектах я делала руками – программировала на «семерке», работала и аналитиком, и постановщиком, и со стороны заказчика, и со стороны внедренцев, разработала с нуля не одну конфигурацию (на той же 7.7 и сейчас с командой на 8.x).

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

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

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

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

Границы и пересечения ролей аналитика и разработчика 1С

Представьте ситуацию: в команде заболел разработчик. Может ли аналитик его заменить? И наоборот – если заболел аналитик, сможет ли разработчик взять на себя его задачи?

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

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

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

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

Наш подход позволяет автоматизировать не выстроенные процессы.

Более того, мы выстраиваем процессы при помощи автоматизации.

Сразу предупрежу, что у моего доклада будет своеобразный «эффект качелей».

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

• А затем я буду вас «приземлять» и показывать практические приемы для выполнения конкретных действий.

Место 1С в Архитектуре компании

Давайте представим, что мы приходим в компанию с нашим продуктом. Что представляет собой архитектура компании:

• В компании есть компьютеры, сети, сервера, ИТ-инфраструктура – то, что составляет технологическую архитектуру.

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

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

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

Давайте подумаем, как наш продукт будет встраиваться во все эти архитектуры:

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

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

• Что касается маршрутизации потоков данных, то когда наша 1С встраивается, она забирает на себя большую часть потоков данных – вся информация теперь идет через 1С.

• А раз вся информация теперь идет через 1С, значит, у нас меняются и бизнес-процессы.

Обратите внимание: вся правая часть – это область разработки.

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

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

Но главная фишка в том, что управление всей архитектурой компании происходит именно через бизнес-архитектуру – через постановку бизнес-целей. Т.е.всем нашим решением управляет именно бизнес-архитектура – именно она задает требования к тому, как полноценно и нормально использовать нашу систему 1С.

Как бизнес-архитектура управляет архитектурой наших решений?

При слове «бизнес-архитектура» у каждого в голове возникает следующая картина.

Можно добавить еще 100 таких экранов с терминами, и они тоже будут иметь какое-то отношение к бизнес-архитектуре.

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

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

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

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

• стратегия, цели и операционная модель;

• структура бизнес-возможностей и функций;

• архитектура процессов;

• организационная структура;

• политики и правила.

Чуть позже мы рассмотрим, как все эти модели собрать в единую структуру.

Я уже говорила, что бизнес-архитектура управляет архитектурой ИТ-решений через процессы.

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

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

Объясню, чем руководствоваться, чтобы описать процесс правильно.

С физической точки зрения у любого процесса есть

• ресурсы на входе,

• переработанные ресурсы на выходе

• последовательность действий или операций внутри по переработке входных ресурсов в выходные.

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

Поэтому, чтобы проверить, правильно ли описан процесс, смотрим:

• что зашло на первую операцию процесса;

• что вышло из первой операции процесса;

• и зашло ли оно куда-нибудь еще – если никуда дальше не зашло, то процесс описан недостаточно и неполноценно. Все.

С точки зрения архитектуры процессов (части бизнес-архитектуры) каждое действие процесса находит некое информационное отражение:

• Создаются документы.

• Появляется новая информация.

• Эта информация куда-то передается, согласовывается, попадает в отчеты.

Эти информационные отражения уже представляют собой архитектуру данных.

Когда мы приходим в компанию с продуктом 1С, ожидается, что в решении будут:

• интерфейсы, в которые можно ввести нужную информацию;

• алгоритмы, которые обработают эту информацию так, как надо пользователю;

• печатные формы и отчеты, которые представят информацию для принятия решений.

Если раскладывать систему 1С на базовые составляющие, то люди от нее ждут именно этого.

В результате архитектура ИТ-решения формируется очень просто:

• берем действие по процессу;

• смотрим, какое информационное отражение оно формирует;

• и продумываем, как это отражается в системе.

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

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

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

• Как удостовериться в полноте и достоверности информации, полученной в процессе обследования и диагностики? Как получить полную, достоверную, актуальную архитектуру процессов и не «утонуть» в рутине?

• Чем руководствоваться при получении противоречивых требований к 1С-решению?

По сути, это та самая задача, которую решают все 1С-ники – взять все действия всех людей компании и переложить их в систему. Осталось только понять, как это сделать корректно.

Технология системного подхода

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

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

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

• воспринимать окружающий мир как систему систем;

• делить эти системы на элементы;

• устанавливать взаимосвязи между элементами и между самими системами;

• понимать, по каким принципам взаимодействуют все эти процессы, системы, операции, подсистемы, надсистемы (какой у них принцип взаимодействия).

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

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

Система – это два или более связанных между собой элементов:

• существующих для достижения цели;

• ограниченных от внешней среды;

• имеющих возможность восполнять внутренние и внешние ресурсы.

Внутри системы всегда существует процесс для достижения цели системы.

Как применить это определение на практике?

Все бизнесы разные. Везде есть свои особенности, которые зависят от разных причин. Но все бизнесы объединяет то, что бизнес – это система.

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

А значит к бизнесу можно применить принципы и правила работы с системами.

Согласно этим принципам:

• Бизнес-система – это способ реализации процесса для удовлетворения потребностей внешней среды (потребности покупателей в продуктах и услугах этой компании).

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

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

Вот так выглядит эта же схема для бизнес-системы.

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

Его важно научиться выделять.

В закупках есть свой базовый процесс, в продажах – свой.

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

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

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

Расскажу, как применить эти теоретические знания на практике.

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

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

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

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

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

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

Без знания того, о чем я рассказываю, это было бы невозможно.

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

Если этого не учитывать, система будет построена на массе условий: если это – делаем так, если то – по-другому.

И как только одно условие сломается – система начнет давать сбои.

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

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

Так мы применяем знание определения системы на практике.

Бизнес – это совокупность систем системного подхода

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

• Первая система – управление основной деятельностью.

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

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

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

Все мыслят локально, в рамках своего участка работы.

А подняться на уровень выше и увидеть общую картину – это как раз навыки крутого специалиста.

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

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

А знаете, для чего нужно знание об этих системах?

Допустим, вас пригласили автоматизировать процесс планирования производства.

Вы сразу понимаете, что без возможности сопоставить план и факт никакое планирование работать не будет, т.е. сначала нужно выстроить процесс отражения факта выпуска. Причем заказчик может этого не осознавать. Он просто говорит: «Хочу планирование».

А вы видите: без отражения в системе факта выпуска плановые значения будут «висеть в воздухе», их нельзя будет сопоставить ни с чем.

Аналогично и с нормативкой: если ее меняют «на лету» и нет процесса согласования при передаче в производство, возникнут сбои.

Например, на производство передали материалы по одной спецификации, а потом спецификацию поменяли. И всё, у нас этап производства не закрывается, потому что выпуск отражен уже по другой спецификации.

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

Но про эти вещи вам никто из заказчиков вам не расскажет.

Зато теперь вы можете с этим знанием прийти и потихоньку заказчику рассказать о порядке выстраивания системы.

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

Должен ли аналитик знать подводки и учить бухгалтера вести регламентированный учет?

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

Тёмно-синим выделены крупные этапы базового процесса. Всё, что внутри этих этапов – пока «чёрные ящики».

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

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

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

Желаю, чтобы информация этого доклада принесла вам пользу на ваших проектах!

Спасибо за внимание!

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

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.