Product planning что это
product planning
Смотреть что такое «product planning» в других словарях:
product planning — a function whereby an enterprise is responsible for the efficient, planning, scheduling and coordination of production activities … Dictionary of automotive terms
Product management — is an organizational function within a company dealing with the planning or marketing of a product or products at all stages of the product lifecycle. Product planning (in bound marketing) and product marketing (outbound marketing) are different… … Wikipedia
Product manager — A product manager researches, selects, develops, and places a company s products. A product manager considers numerous factors such as target demographic, the products offered by the competition, and how well the product fits in with the company… … Wikipedia
Product requirements document — A PRD is often created after a market requirements document (MRD) has been written and been given approval by management, and is usually written before (or at least concurrently with) a technical requirements document. It is designed to allow… … Wikipedia
planning — See product planning … Dictionary of automotive terms
Product lifecycle management — (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal. [cite web title = About PLM publisher = CIMdata url = http://www.cimdata.com/PLM/aboutPLM.html ] PLM… … Wikipedia
Product based planning — is mandated for PRINCE2 projects and is a method of identifying all of the products and associated work required to complete a project.DescriptionProduct based planning is intended to ensure that all of the necessary products that will go towards … Wikipedia
Product data management — (PDM) is the business function within product lifecycle management that is responsible for the creation, management and publication of product data. Introduction Product data management (PDM) is focused on information relative to core operations… … Wikipedia
Planning poker — is a consensus based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development. It is a variation of the Wideband Delphi method. It is most commonly used in agile software development,… … Wikipedia
planning — plan‧ning [ˈplænɪŋ] noun [uncountable] when you think carefully about something you want to do in the future, and decide exactly how you will do it: • If you want to ensure a trouble free retirement, it s never too early to start financial… … Financial and business terms
Product marketing — deals with the first of the 4P s of marketing, which are Product, Pricing, Place, and Promotion. Product marketing, as opposed to product management, deals with more outbound marketing tasks. For example, product management deals with the nuts… … Wikipedia
Как правильно готовить продуктовую стратегию? Руководство для менеджеров продуктов
Без сильной и уверенной стратегии в управлении продуктом делать нечего. Любой начинающий менеджер продукта должен стремиться развивать в себе умения и навыки, которые помогут выстраивать стратегию как великие и дальновидные полководцы. Важными составляющими создания эффективной стратегии являются умение качественно планировать, определять приоритеты идей и задач и оценивать их.
Помните правила великого Кутузова, который четко и ясно видел стратегические цели? Он считал, что стратегия должна всегда превалировать над тактикой. Для победы вполне допустимо пожертвовать отдельной битвой, ведь «главное не крепость взять, а войну выиграть».
В управлении продуктом все решается мирным путем, однако управленцам следовало бы многому поучиться у полководца. Этот материал будет полезен тем, кто стремится стать гуру в стратегическом планировании и научиться грамотно приоритизировать.
Стратегия продукта – основа деятельности управленцев
Все начинается с четкой и гибкой стратегии. Определение стратегии в самом начале жизненного цикла продукта происходит по принципу «must have». Хорошая стратегия должна удовлетворять потребности ваших клиентов и помогать им реагировать на внутренние потребности компании. Если у вас нет четкой стратегии, то о приоритизации функций думать рано.
Когда менеджеры продуктов разрабатывают свои стратегии, они определяют основные характеристики продукта и особенности клиента, необходимые для достижения успеха.
Что такое стратегия?
Любая стратегия направлена на достижение конкретной цели. Это реальный маршрут от точки A в точку Б.
Эффективная стратегия — это комплекс действий, которые заслуживают доверия, они согласованы и направлены на преодоление больших препятствий на пути достижения конкретной цели
Ричард Румельт
Эффективная стратегия должна включать в себя следующее:
Любая продуктовая стратегия состоит из 4 частей:
Видение продукта
Product vision или видение продукта включает информацию о возможностях рынка, целевых клиентах, позиционировании продукта, конкурентном анализе и рыночном плане. Успех продукта в конечном итоге достигается, если продукт выходит на новых пользователей и доставляет им определенную ценность.
Цели продукта
Цели должны быть измеримыми и актуальными, четко определяться конкретными метриками. Они помогают менеджерам продуктов установить, чего они хотят достичь в следующем квартале или другом временном отрезке (увеличить доходы, расширить присутствие в новых странах, повысить мобильную адаптацию и т. д.)
Метрики
Метрики позволяют измерять ход и прогресс достижения целей. Среди множества доступных метрик, очень важно выбрать подходящие именно для вашего продукта.
Конкретный план действий
Здесь должны быть доступно расписаны все этапы и шаги по достижению стратегии.
Одним из эффективных способов планирования является система, которую предлагает Itamar Gilad — опытный консультант в области управления продуктами и успешный спикер. В своем подробном материале на Hackernoon он описывает полезность и ценность GIST-планирования и предлагает внедрять его в работу вместо традиционных product roadmap.
Планирование по системе GIST
Проблематика
К сожалению, часто планы быстро расходятся с реальностью. Дорожные карты и диаграммы Ганта (Gantt Charts), безусловно, полезны, но в них нет места для маневренности.
Дорожные карты позволяют работать только с несколькими крупными проектами, поэтому приходится расставлять приоритеты и выбрасывать многие потенциально хорошие идеи. В иерархических компаниях идеи-победители приходят от руководства. В более демократических компаниях добиться признания идеи сложнее, поэтому питчинг и умение убеждать и продавать стали обязательными навыками менеджеров продукта.
Решение
Использование системы планирования GIST помогает решить эту проблему: вы получаете легкие планы с возможностью изменений. Они уменьшают расходы на управление, улучшают производительность команды и, в конечном итоге, позволяют добиться более качественного продуктового решения.
Авторская система GIST состоит из четырех элементов. Она называется по первым буквам ее основных блоков:
G – goals (цели)
Цели описывают стратегию компании с точки зрения желаемых результатов: где мы хотим быть? когда и как мы узнаем о том, что мы их достигли? Всякий раз, когда кто-либо в организации задается вопросом: «Почему мы делаем этот проект?», цель должна давать ясный ответ.
I — Ideas (идеи)
Идеи — это гипотетический способ достижения целей. Гипотетический потому, что у вас может быть много идей для достижения заданной цели, но только 1–3 из них приведут к положительному результату (а часто соотношение и того хуже). Причем у крутых менеджеров продуктов коэффициент не больше. Поэтому GIST исключает, что вы:
S — Step projects (проекты)
Большой проект разбивается на мелкие проекты, которые длятся не более 10 недель и выполняются по очереди. Например:
Детализированный статичный прототип → Интерактивный прототип → MVP → Dogfood → Beta → Launch.
Каждый такой проект — это эксперимент, который проверяет идею. То есть с каждым проектом вы получаете все более полную версию идеи и проверяете ее на более широкой аудитории в течение все более длительного времени.
Конечный продукт, как правило, намного лучше, чем тот, который вы себе представляли изначально. Неработающие идеи отсеиваются рано, а идеи, которые работают, получают больше инвестиций.
Возможность придумать идею и уже через пару недель внедрить ее в продукт — очень сильно вдохновляет. Вы никогда больше не захотите делать громоздкие проекты.
T – Tasks (задачи)
Каждый проект разбивается на задачи. Эта часть системы планирования отлично помогают визуализировать Agile-ориентированные инструменты для планирования, Kanban-доски, и современные технологии для управления проектами.
На этом уровне вам скорее всего ничего не придется менять.
Планирование с помощью GIST многоуровневое и итеративное:
Как упростить GIST?
Step projects действительно полезны для крупных проектов, потому что они помогают как можно скорее подтвердить идеи и не тратить огромные суммы на полную разработку идей. Для мелких проектов это не всегда уместно. К примеру, в разработке мобильных приложений вы можете действовать без Step Projects.
Поэтому после того, как вы выбрали лучшие идеи с помощью приоритезации, вы готовите задачи для их реализации, собираете требования, записываете спецификации и отправляете их в разработку. В конце спринта вы можете собирать данные и отзывы пользователей. Эта иерархия выглядит так:
Сила приоритизации
Разобраться с важностью и срочностью фич и задач помогают разные способы и подходы приоритизации.
Первый подход, на котором остановимся, представляет собой фреймворк, который считается достаточно эффективным и мощным и не занимают много времени и усилий – 2×2 матрица. Это простая и быстрая система определения приоритетов.
Матрица 2×2 для определения приоритетов
Классический подход, основанный на матрице Эйзенхауэра, состоит из двух осей. Выбрав рамки, вы можете установить свои собственные критерии и оценить идеи, фичи и задачи продукта. Например, такие методы приоритизации, как Value vs Effort, Value vs Risk, Value vs Cost могут быть легко визуализированы с помощью этой структуры.
В Hygger, визуализировать матрицу помогает инструмент Priority Chart (доступен только для Value & Effort приоритизации):
Метод ICE Scoring
Метод ICE — это простой способ определить приоритетность функций продукта без дополнительных требований. Все, что вам нужно, это рассчитать баллы за идею, согласно формуле: 
Метод RICE Scoring
Метод RICE – еще один интересный способ приоритизации идей и фич продукта. Аббревиатура включает 4 фактора: Reach (охват), Impact (влияние), Confidence (уверенность в вашей оценке охвата, влияния и трудозатрат), Effort (трудозатраты).
Чтобы получить оценку по RICE, вам необходимо объединить эти факторы.
Скоринг фич
Яркий пример оценки фич – метод Weighted Scoring. Этот метод позволяет вам рассматривать фичи, ранжировать их с помощью специального фреймворка по ряду критериев и использовать оценки, которые вы сами придумали. Это недорогой и удобный способ определить относительную ценность любого количества задач, над которыми вы можете работать.
Критерии оценки выбираются индивидуально. Они могут быть выбраны на основе четко определенных целей продукта и метрик. Например:
Только после того, как группа обсудила эту идею, вы можете перейти к оценке. Такой принцип у метода Planning Poker, который в оригинале использовался для оценки задач для спринтов, а сейчас часто применяется менеджерами и для оценки идей.
Принцип Planning Poker
Planning Poker или Покер планирования впервые был описан Джеймсом Греннингом в 2002 году.
Для проведения необходимо подготовить список обсуждаемых фич и несколько колод карт. Список фич или пользовательские истории описывают разрабатываемое ПО. Карты в колодах должны быть пронумерованы. Чаще всего это карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Некоторыми организациями используются обычные игровые карты, включающие туз, 2, 3, 5, 8 и короля.
Все оценивающие выбирают одну карту для представления их оценки. В то же время открываются все карты. Если все оценивающие выбрали одно и то же значение, это и станет оценкой. Если нет, то все обсуждают свои оценки.
Другие методы и техники приоритизации
К радости менеджеров продуктов, сегодня существует множество специальных техник и фреймворков для работы с приоритетами. Об этом написано много; перечислим некоторые из них:
Что в итоге?
Если способ приоритизации выбран и реализован успешно, то все довольно просто: все задачи идут в разработку по Scrum или Kanban, а менеджеру продукта остается отслеживать их прогресс и наслаждаться успешно реализуемой стратегией.
Возможно, первые результаты работы со стратегией и технологиями приоритизации сразу не сделают вас Кутузовым или Наполеоном в управлении продуктами, но однозначно повысят ваш профессиональный уровень и придадут уверенности в дальнейших делах.
А какие ваши секреты работы с продуктовой стратегией? Считаете ли вы умение приоритизировать основополагающим в работе менеджера продукта?
Автоматизация бюджетирования: содержание проблем, принципы их решения и сравнение программных продуктов (BI / ERP / EPM)
О чем статья?
Это обобщенная статья о том, что такое «автоматизация бюджетирования», из каких проблем состоит эта сфера и какие IT-инструменты в ней используются.
Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем – вам сюда.
Если вы технический архитектор, который никогда не работал с предметной областью бизнес-планирования – статья тоже для вас.
Сразу предупреждаю, что я постарался писать статью максимально простым языком, чтобы она была понятна для всех.
Почему я решил ее написать?
Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:
Приглашаю всех, кто работает в качестве консультанта/пользователя с системами бюджетирования, к участию в пополнении данной статьи.
Если не специализироваться на этом рынке, угнаться за трендами во всех продуктах практически невозможно. Функциональность постоянно изменяется, а информация все больше закрывается вендорами.
Поэтому буду очень благодарен, если специалисты смогут поправить меня (если я допустил неточности) и дополнить статью информацией по известным вам продуктам в следующих аспектах:
ПРОБЛЕМЫ И ПРИНЦИПЫ ИХ РЕШЕНИЯ
Понятие «Управленческий учет» можно рассматривать в двух вариантах: 1) многоуровневая система фактического учета 2) многоуровневая система фактического учета и планирования. При этом управленческий учет ведется и в финансовом, и в нефинансовом выражении (на низших уровнях чаще используются натуральные показатели, а финансовые показатели – важны на верхних). Бюджетами же обычно называют верхнеуровневые финансовые планы.
Поэтому. Если считать УУ – только учетом фактических данных, то УУ и бюджетирование – совершенно разные вещи. Если же считать, что УУ – это и «план», и «факт», то бюджетирование можно считать частью управленческого учета на его верхних уровнях.
В бюджетирование входит два основных вида деятельности:
Архитектурные отличия между учетом и планированием заключаются в том, что данные учета идут «снизу вверх». Чтобы получить качественную отчетность, нужно организовать запись как можно более детальных фактов. Тогда любую сводную информацию (важную для руководителей) можно будет получить простой агрегацией.
Поэтому в учете оптимально работает схема Документ –> Таблица (Регистр) –> Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).
Рис. 1. Учетная схема «Документ –> Регистр –> Отчет»
Планы же изначально – укрупненные. Поэтому вводить их удобно именно «сверху» (то есть, в таких же формах, в которых формируются отчеты).
Поэтому при попытке построить автоматизацию бюджетирования по аналогии с обычным учетом (рис. 3), перед компаниями сразу встают три ключевые проблемы.
Рис. 3
Проблема 1: Администрирование правил. Администрировать правила трансформации данных (из низших уровней учета – в формат бюджетирования), прописанные в коде отчетов – очень неудобно и трудозатратно.
Проблема 2: Скорость «сбора факта». Планы выводятся в отчеты очень быстро (поскольку хранятся в уже укрупненном виде), а фактические данные – агрегируются очень медленно.
Первые две проблемы – связаны не только с бюджетированием, и в целом представляют основу всей предметной области хранилищ данных, интеграции данных и ETL.
Третья проблема – специфическая проблема планирования. Которая, собственно, является одной из важных проблем ERP-систем как реал-таймовых инструментов (предназначенных не только для «посмертного» учета произошедших событий, а для планирования и оперативного контроля бизнеса).
Теперь рассмотрим каждую проблему подробнее.
Проблема 1: Администрирование правил трансформации
На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.
Сложность правил трансформации
Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения – к организации; от склада – к региону; от номенклатуры товара – к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.
В бухгалтерском учете используются одни статьи, и они заполняются в учетных документах.
В бюджетировании используются другие статьи, но «факт» бюджета собирается из данных бухучета.
Вы можете представить, насколько значительную проблему составляет поддержание такого кода для программистов, если таких статей несколько сотен, они используются в десятке разных отчетов, и правила для их определения в управленческом учете могут корректироваться раз 3-4 месяца.
Решение проблемы 1: mapping
Для решения этой задачи mapping – соответствия между полями разных уровней и/или видов учета и отчетности – можно вынести из отчетов, создать как отдельный объект, настраивать и хранить отдельно, и затем обращаться к ним при необходимости.
Рис. 4
Это дает сразу два преимущества:
Но разработать инструмент для удобного маппинга больших объемов справочников – непросто.
Проблема 2: Скорость трансформации фактических данных
Решение проблемы 2: хранение трансформированных данных
Чтобы не вычислять данные отчетов «на лету», их можно хранить уже в укрупненном и трансформированном виде.
Для этого, помимо исходных таблиц (которые все равно понадобятся в компании), нужно создать таблицы для хранения агрегированных фактических данных. Это могут быть и отдельные таблицы, и общая таблица и для «плана», и для агрегированного «факта».
Конечно, эти таблицы предварительно нужно как-нибудь заполнять: для этого будем выполнять такую же процедуру трансформации, что выполнялась раньше при формировании отчета, но теперь вынесем ее в отдельный фоновый процесс.
Рис. 5
С этой проблемой связана сфера Хранилищ данных (DWH).
Грубо говоря, DWH – это и есть место (таблица или, на практике, множество связанных таблиц) для хранения промежуточно вычисленных (агрегированных или еще как-то трансформированных) данных.
ETL-процессы
ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).
Но обычно этот термин употребляют именно в случаях, когда данные после трансформации куда-то записываются для хранения. То есть, процедура трансформации, выделенная на рис. 5 — это ETL.
У такого подхода есть плюсы:
Проблема 3: Форма ввода бюджетов
Дело в том, что в классическом виде отчеты в программных продуктах – это средство вывода данных. Но вводить данные в них нельзя.
Поскольку фактический учет идет «снизу вверх» (от фактов к суммам), в нем это не является проблемой, и потребности вводить укрупненную информацию вручную обычно нет.
То есть, если мы выстроили детальный учет по товарам (как показано в документе на рис. 2), обычно нет ни потребности, ни смысла вводить фактические данные в таком укрупненном виде, как они выглядят в отчете на том же рис. 2.
Таким образом, форма ввода сильно отличается от формы вывода.
А вот для бюджетирования классическая схема «Форма ввода» (документ) –> внутренние таблицы –> Форма вывода (отчет)» не подходит.
Например, в свое время мы разработали помесячный отчет по закупкам (как на рис. 2), а теперь начинаем вести планирование, и финансовый директор хочет вводить бюджет закупок в такой же форме.
Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).
Первое. Нам придется разработать два технически разных объекта (отчет по закупкам и форма для планирования закупок), которые внешне должны быть идентичны.
И нам придется их поддерживать. То есть, если форма бюджета закупок должна измениться, скорее всего она изменится и для «плана», и для «факта», и нам придется вносить изменения в обе эти формы.
Второе. При вводе плана хочется видеть факт. А если формы отчета и ввода — разные объекты, делать это неудобно.
Решение проблемы 3: интерактивные формы ввода-вывода
Решение тоже очевидно: вместо привычных «документов» и «отчетов», нужно создать объект, который позволит одновременно и читать, и вводить данные.
Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными – то есть, работать наподобие того, как позволяет работать Excel.
При этом планы после ввода можно «складывать» в то же самое хранилище данных, где лежат фактические данные (см. рисунок).
Рис. 6
Но реализовать такие формы значительно сложнее, чем обычные отчеты или документы в учетных системах.
Степень интерактивности может быть разной: проще реализовать заранее настроенные формы, сложнее – динамические (где заранее неизвестно количество колонок/строк, но заранее заданы их типы). Еще сложнее – позволять в пользовательском режиме «вращать» данные, строить новые формы и задавать произвольные формулы расчета, меняя структуру отчетов.
Решение проблемы 4: кубы
Есть и еще один инструмент, который решает проблему, не обозначенную выше.
Дело в том, что при больших объемах данных, при высокой интерактивности и при сложных формулах, обычные реляционные SQL-таблицы, в которых принято хранить данные ERP-систем, не обеспечивают максимальной скорости обработки данных в режиме реального времени.
Для решения такой задачи можно применять хранение данных не в виде таблиц, а сразу в виде кубов.
Куб, OLAP-куб, OLAP-таблица, многомерная база данных, аналитическая база данных, столбцовая база данных – это названия способов хранения данных, позволяющих хранить их сразу на пересечении множества разрезов. Из таких таблиц проще получать различные срезы, а также они быстрее проводят разные расчеты(например, распределение затрат в различных измерениях). Поэтому они подходят для анализа «Что-если» — позволяют моделировать разные сценарии бизнеса и тут же получать ответ, как при изменении одних показателей изменятся другие.
На самом деле, здесь может быть несколько различных технологий, и формально, например, столбцовая база данных отличается от многомерной. Но это уже детали, углубляться в которые в рамках данной статьи уже негде.
Правда, если для задач бюджетирования сразу организовать хранилище в виде куба – это хороший и подходящий вариант, то для других задач бизнеса многомерная модель хранения может не годиться, и хранилище организуют по другой технологии. В таком случае куб может добавляться к «основному» хранилищу, как еще одно звено в архитектуре.
ВИДЫ ПРОГРАММНЫХ ПРОДУКТОВ В БЮДЖЕТИРОВАНИИ
Теперь рассмотрим виды информационных технологий, которые решают задачи, важные при автоматизации бюджетирования:
Но в реальности границы немного размываются, и часто продукты «умеют» делать смежные вещи. Очень приблизительно перекрытие функций выглядит так:
Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно. То есть, обычно инструмент, который предлагает дополнительные функции, не выполняет их так же хорошо, как отдельная специализированный инструмент!
Если потребность в какой-либо специфической функции в компании максимально развита, желательно добавлять в контур IT-ландшафта компании (покупать или разрабатывать) отдельную систему, специализирующуюся на данной функции.
Поэтому, например, при максимальной потребности в DWH в компании, приобрести EPM-систему будет недостаточно, и лучше строить отдельную DWH; отдельная BI система может обладать более гибкими и шустрыми возможностями визуализации, чем комплексное EPM-решение и так далее.
Карта видов ПО в бюджетировании
В целом, визуально покрытие разных задач по автоматизации бюджетирования, разными типами информационных систем, можно показать приблизительно так:
Рис. 7
Теперь рассмотрим, какую архитектуру бюджетирования предлагают некоторые популярные программные продукты.
БЮДЖЕТИРОВАНИЕ В ERP-СИСТЕМАХ
Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.
На мой взгляд, «классический» функционал ERP включает учетную систему; конструкторы отчетов; функции оперативного контроля планов и, конечно же, базовые возможности их ввода.
Не включает: возможность сбора данных из множества распределенных источников; построение кубов и гибкой интерактивной аналитики.
Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.
А теперь рассмотрим бюджетирование в конкретных ERP-системах.
1C: УПП
В УПП реализована следующая схема, но внутри одной базы.
Рис. 8. Архитектура бюджетирования в 1С: УПП
Плюсы бюджетирования в УПП:
Недостатки бюджетирования в УПП:
1C:ERP
Насколько помню, изначально ERP предусматривала только «онлайновую» модель сбора отчетности. И на сегодняшний день во многих компаниях основной сценарий работы именно такой. Тем не менее, сейчас программа позволяет промежуточно хранить вычисленные значения.
Рис. 9. Архитектура бюджетирования в 1С:ERP
Плюсы бюджетирования в 1С:ERP:
1C: КА
«Комплексная автоматизация» представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.
MS Axapta / MS Dynamics AX
Предусматривается только «онлайновая» модель просмотра фактических данных бюджетов – они читаются напрямую из собственных модулей бухгалтерского учета, при этом возможности серьезной трансформации не предусмотрены.
Рис. 10. Архитектура бюджетирования в MS Dynamics
И плюс, и минус системы – ее «заточенность» на собственные учетные модули Dynamics и их готовую структуру.
SAP S4 HANA
Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.
Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать отдельной EPM-системой «поверх» ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему (в SAP S4 HANA Cloud). Подробнее о SAP BPC будет ниже.
Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).
Таким образом, SAP переходит к архитектуре, противоположной той, что сегодня хорошо известна в «обычной» практике. В нем аналитическая база данных строится не «над» храналищем (SAP BW), а реализована «под» ERP-системой. При этом хранилище данных (SAP BW), когда пользователь работает с его данными из EPM-системы, передает данные для вычислений обратно в эту исходную комбинированную базу HANA.
Фактически, тот же эффект, ради которого задумывались технологии IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.
Oracle Cloud ERP
Oracle также пошла по пути встраивания EPM-системы внутрь ERP.
Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion (о котором мы тоже поговорим ниже), компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.
BI-СИСТЕМЫ
BI-системы (Business Intellegence) в «чистом» виде – это средство вывода данных. То есть, BI – это конструкторы отчетов и дашбордов, которые обычно также содержат базовые функции реструктуризации и анализа данных (например, позволяют соединять таблицы, находить усредненные тренды и пр.).
EPM-СИСТЕМЫ
EPM – сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).
Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных «План-факт» форм. Понятие EPM еще не стало общеприименимым на русскоязычном рынке, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте BI, корректнее называть именно EPM-системами.
Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), которые выходят за рамки сводной отчетности, калькуляций и планирования. Но мы будем рассматривать EPM именно в части систем для автоматизации бюджетирования. Поэтому, например, мы будем называть продукт SAP Business Planning & Consolidation (SAP BPC) – EPM-системой, несмотря на то, что сам SAP называет ею более крупный продукт SAP EPM, в который включается SAP BPC.
Как мы упоминали, BI не позволяет вводить данные. EPM обычно включают в себя стандартные функции BI, а кроме этого реализуют возможность ввода и записи данных.
Бит.Финанс
Бит.Финанс основан на методологии бюджетирования УПП, однако, в отличие от него, во-первых, поддерживается и развивается, а во-вторых, реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из внешних источников).
Рис. 11. Архитектура бюджетирования в Бит.Финанс
Плюсы автоматизации бюджетирования в Бит.Финанс:
Получение фактических данных работает в трех вариантах:
Anaplan
Флагманский продукт, недавно набравший большую популярность на мировом рынке. Предлагается только в облачной версии.
В отличие от остальных популярных решений (в т.ч. Hyperion и Planning Analytics), имеет немного специфическую специализацию: он лучше всего работает как калькуляционный сервис, который позволяет быстро автоматически пересчитывать объемные бюджетные модели с большим количеством зависимостей.
Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)
И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс — в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа «Что-Если», расчета и утверждения планов (бюджетов), и планировать архитектуру заказчика нужно исходя из этого. Минус – в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.
В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможность легко «перегонять» данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (особенно с учетом того, что тарификация строится в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.
Поскольку он не заменяет собой универсальное корпоративное хранилище, в определенных случаях он может использоваться как калькуляционный сервис, далее «складывающий» плановые данные в собственное DWH компании, откуда для построения быстрых отчетов и дашбордов данные передаются в отдельную BI-систему.
Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)
В целом, использование одновременно EPM и BI-систем является нормальной практикой.
Oracle Hyperion
Поставляется минимум в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.
Из-за экосистемности, архитектуры могут приобретать самые разные виды, но типовая выглядит примерно так.
Рис. 14. Архитектура бюджетирования в Hyperion (возможный вариант)
На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.
В качестве ETL-решения предлагается Oracle Data Integrator, который выступает как универсальный механизм интеграции данных в экосистеме Oracle.
Плюсы автоматизации бюджетирования в Oracle Hyperion:
IBM Planning Analytics
В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognos’а).
Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.
Типичная архитектура очень похожа на Hyperion.
Рис. 15. Архитектура бюджетирования в Planning Analytics (возможный вариант)
Сильные стороны IBM Planning Analytics:
SAP BPC
В целом, отличительные особенности SAP – экосистемность, сложность архитектуры и инфраструктуры решений.
Как я уже говорил, SAP в разное время поддерживал и поддерживает различные варианты архитектуры; по наиболее свежей информации, флагманская версия архитектуры, рекомендуемая вендором на сегодняшний день, выглядит так:
Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)
Преимущества бюджетирования на базе SAP BPC:
ETL-ИНСТРУМЕНТЫ
Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения: