Публикации Александра Карпова > Проект по созданию программного комплекса «ИНТЕГРАЛ»
До этого проекта у меня не было личного опыта в реализации ИТ-проектов. Я наблюдал за реализацией одного ИТ-проекта, когда работал в консалтинговой компании наемным сотрудником. Речь идет о консалтинговой группе БИГ, в которой я проработал 7 лет (с 1995-го по 2003-й год). Там ИТ-проект был реализовано с очень большой эффективностью и получился весьма коммерчески успешным.
Все началось с того, что сначала к нам на короткий бесплатный семинар по организационному проектированию приехали представители компании «Сибирский алюминий» (сейчас «Русский алюминий»). Как раз я проводил этот семинар. Тогда я еще только учился проводить семинары. Начинал именно с бесплатных, чтобы участники особых претензий не могли предъявить за не очень качественное проведение. Как говорится, на халяву и уксус сладкий.
Потом они заказали проведение корпоративного семинара, который проводил уже наш шеф. Семинар проводился в Красноярке. Я должен был лететь вместе с шефом, но я умудрился за несколько дней до вылета опоздать на работу на 15 минут и в качестве наказания меня сняли с этого проекта. Как мне потом рассказал коллега, который полетел вместо меня, это был чартерный рейс. В самолете из пассажиров были только представители компании, мой шеф и коллега, а также группа «Стрелки». Олды помнят, чтоэти поющие трусы этот женский коллектив был очень популярными в девяностые. В общем, пока летели все там перепились и стали гоняться по самолету за стрелками. Поскольку я не полетел, то мне не удалось стрелок помацать :)).
Через месяц после семинара у нас начался проект по организационной структуризации, в рамках которого была проведена не только организационно-методологическая работа, но и разработан программный продукт для моделирования организационной структуры. Я непосредственного участия в разработке ТЗ для программного продукта не принимал. Этим занимался мой коллега, который как раз летал на корпоративный семинар вместе со «Стрелками». Кстати, он так мне и не признался, гонялся ли он сам за этими «Стрелками» или нет. Все-таки он женатый был, поэтому зашифровался и ничего не рассказывал. Мало ли, вдруг как-то инфа и до жены дойдет.
Можно сказать, что этот проект для нас был одновременно и текущим, и проектом развития. Текущим -- потому что мы на нем заработали; развития -- потому что мы еще и создали актив (тот самый программный продукт), который в дальнейшем приносил нам дополнительную прибыль. Мы стали продавать этот программный продукт и как коробочное решение, и применяли его при реализации консалтинговых проектов по организационной структуризации компаний и групп.
Когда мой коллега, курировавший проект по разработке данного программного продукта, ушел из этой компании и запустил свой консалтинговый бизнес, то он как-то договорился с программистом и тот, уж не знаю на каких условиях, передал исходный код. Потом он существенно развил эту программу.
В общем, конкретно этот ИТ-проект мне показался совсем несложным. Поэтому, когда встал вопрос о реализации собственного ИТ-проекта, я посчитал, что ничего супер-рискованного в нем нет.
Мы стали изучать уже имеющийся софт для автоматизации бюджетирования и управленческого учета. Я понимаю, что, мягко говоря, не совсем корректно как-то очернять конкурентов, но по крайней мере на тот момент времени (2005-й год) все, что тогда было на рынке, – это любое говнище. Поверьте, это я еще подбирал слова. Сразу оговорюсь, мы не изучали «тяжелые» системы, на которых сидит крупняк. Возможно, там эти модули реализованы не через задницу.
Мы понимали, что не можем ничего толкового посоветовать клиентам, поэтому постепенно пришли к пониманию того, что нам нужно разработать собственный софт под нашу методологию бюджетирования и управленческого учета.
Кстати, подробнее о разработке этих методик можно прочитать (или посмотреть видеоролики) на следующих страницах одного из наших сайтов:
– самая проработанная методика бюджетирования;
– самая проработанная методика управленческого учета.
Итак, было принято стратегическое решение о реализации ИТ-проекта по разработке собственного софта для автоматизации бюджетирования и управленческого учета. Начать мы, естественно, решили с разработки модуля «Управленческий учет» для автоматизации факта, поскольку автоматизировать планирование значительно сложнее.
Дело в том, что принципы и концепция планирования и учета существенно различаются. Концептуальная модель формирования фактической управленческой отчетности представлена на рисунке 1, а плановой – на рисунке 2. Подробнее об этом можно прочитать в книге «Эффективная система бюджетирования и управленческого учета. Практические советы и рекомендации».
Рис. 1. Концептуальная модель формирования фактической управленческой отчетности
Рис. 2. Концептуальная модель формирования плановой отчетно-сти
После того, как мы разобрались с автоматизацией фактического управленческого учета, перешли к автоматизации модели планирования. Честно говоря, на решение данной задачи у нас ушло больше времени.
Мы решили, что будем придерживаться стратегии гибкой автоматизации, когда все необходимые настройки модели и регламента бюджетирования и управленческого учета осуществляются не программистом (изменение программного кода), а экономистом с помощью специального конструктора (или мастера). Если человек знает методологию бюджетирования и управленческого учета, он должен иметь возможность настроить автоматизированную модель и регламент без помощи программистов. Поэтому мы стали придерживаться логики, представленной на рисунке 3.
Рис. 3. Проектирование и автоматизация финансовой модели бюджетирования и управленческого учета
Перед тем, как заниматься автоматизацией, нужно сначала определиться с показателями и с форматами фактической и плановой отчетности. Затем нужно разработать модель (методику) формирования каждого показателя в фактической и плановой отчетности. До этого момента еще никакой автоматизации вообще нет.
Дальше возможны два варианта: жесткая и гибкая автоматизация. В первом случае программистам передается ТЗ с описанием модели формирования плановой и фактической отчетности. Программисты сами занимаются настройкой этих модели через написание кода. Соответственно, если что-то нужно будет поменять, придется каждый раз обращаться к программистам. Каждое вмешательство в код увеличивает риски ошибок. Причем не все ошибки сразу могут проявиться.
Гибкая стратегия автоматизации не подразумевает программирования. Настройка модели осуществляется с использованием вышеупомянутого конструктора (мастера) для настройки модели. Понятно, что сам конструктор построен на основе определенной модели, которая уже не меняется. Точнее говоря, ее можно изменить, но для этого уже придется менять код.
Примеры настройки методики (модели) учета и планирования представлены на рисунках 4 и 5.
Рис. 4. Пример настройки методики (модели) учета
Рис. 5. Пример настройки методики (модели) планирования
Таким образом, нам удалось разработать программу, в которой вся модель и регламент бюджетирования и управленческого учета настраивались экономистами без привлечения ИТ-специалистов и тем более программистов. Участие ИТ-специалиста требовалось только для установки программы и базы данных. В итоге нам удалось разработать программный продукт, соответствующий нашей технологии управленческого учета и бюджетирования.
Поскольку к нам за автоматизацией обращались не только компании, но и холдинги, мы реализовали возможность настройки консолидированной модели.
На самом деле необходимость консолидации может возникнуть и у одной компании, если она использует несколько юрлиц. В таком случае нужно будет консолидировать фактические данные из разных баз. Для этого должна быть реализована возможность настройки такой модели.
Стоит отметить, что для формирования самих отчетов мы использовали многомерный иерархический OLAP-куб. Мягко говоря, не во всех программах реализована такая возможность.
Это особенно актуально, когда у компании возникает потребность в детализации отчетности. В таком случае с помощью OLAP-куба можно один и тот же отчет выводить в различных вариантах в зависимости от набора аналитик у каждого показателя отчета.
Вынужден признаться, что я не сразу сориентировался в многомерной отчетности. Пришлось учиться многомерному мышлению, поскольку до этого я разрабатывал финансово-экономические модели только в Excel.
В электронных таблицах в основном работаешь со скалярными величинами. Проще говоря, настраиваешь формулу, связывая между собой ячейки.
В нашем программном продукте при разработке модели приходится работать с векторами с максимальной размерностью, равной трем. То есть каждый показатель (строка отчета) может иметь от нуля (тогда это скаляр) до трех аналитик. Например, выручка от реализации может детализироваться по продуктам, каналам сбыта и филиалам.
Когда связываешь формулами скалярные величины всегда получается скалярная величина. А когда проделываешь то же самое с векторами, результат получается неоднозначным. Поэтому нам пришлось разработать свои правила вычисления.
Бывают очевидные ситуации. Например, из выручки, детализированной по продуктам (одномерный вектор), вычитается себестоимость, тоже детализированная по продуктам. В этом случае результатом тоже будет одномерный вектор -- валовая прибыль с детализацией по продуктам.
Но пользователь программного продукта может настроить какую угодно формулу и не обратить внимание на размерность. Например, может из выручки, детализированной по продуктам, вычесть операционные расходы, детализированные по статьям затрат. Оба показатели являются одномерными векторами, но аналитики то у них не совпадают.
Короче говоря, при работе с многомерными объектами возникает много всяких нюансов, которые нужно учитывать и в которые нужно въехать.
Нам очень повезло с программистом. Очень толковый попался. Причем он сам генерировал интересные идеи, которые реализовывал после согласования с нами.
На момент разработки нашей программы и до закрытия проекта это было очень крутое решение, значительно превосходившее аналоги. Еще раз отмечу, что с большими ERP-системами мы не конкурировали.
Честно говоря, в тот момент времени не было особой возможности заниматься маркетингом. Сайты, к сожалению, пока еще не были раскручены (подробнее об этой моей стратегической ошибке написано в статье «Стратегические косяки в создании и продвижении сайтов»). Основным источником клиентов тогда были книги. Клиентов, приходивших по книгам, хватало для семинаров и консалтинговых проектов, но для того, чтобы зарабатывать на продаже «коробок», поток должен был быть намного больше.
Мы пробовали заниматься и активными продажами, но умудрились запустить этот проект прямо в самый разгар кризиса, поэтому его пришлось вскоре закрыть (подробнее об этом написано в статье «Создание отдела маркетинга и продаж»).
Вкладывать значительные средства в оперативную рекламу тогда не было возможности, поскольку, во-первых, после кризиса мы еще не восстановились, во-вторых, я женился (это самая большая стратегическая ошибка в моей жизни), в-третьих, родился первый ребенок, в-четвертых, влез в ремонт дома, а это, как оказалось, намного более проблематичнее и затратнее, чем ремонт квартиры (даже если квартира такого же метража). После этого ремонта я даже написал книгу для тех, кто хочет сохранить время, деньги и нервы при ремонте. Она называется «Наилучший ремонт квартир, таунхаусов и домов. Как сохранить деньги, время и нервы».
Из-за того, что все деньги под ноль уходили на ремонт и семью, я даже перестал переиздавать старые книги и издавать новые. Поэтому и данный стратегический маркетинговый инструмент стал приносить меньше клиентов.
Я еще раз убедился в том, что больше всех зарабатывают те, кто вкладывается в маркетинг, а не в разработку продукта (R&D). По крайней мере в нашей стране это так.
У меня ведь было два наглядных примера. Как выше я уже написал, в группе БИГ я проработал с 1995-го по 2003-й, но примерно на год уходил в другую консалтинговую компанию, а потом вернулся. В плане развития своего потенциала разработчика и производственника за год в этой компании я продвинулся намного больше, чем за 7 лет в БИГе (подробнее о составляющих рабочего потенциала человека и о том, как его нужно развивать, написано в книге «Максимизация личного заработка: стратегия и конкретный план»). Сотрудники этой небольшой консалтинговой компании как эксперты были несопоставимо более продвинутыми, чем консультанты группы БИГ, но с маркетингом у них было, мягко говоря, не все в порядке.
В группе БИГ, наоборот, не было отбоя от клиентов, правда, до поры до времени. Просто владелец этой компании очень грамотно вложился в маркетинг. Причем вложения его составили 0 рублей 0 копеек. В итоге компания все-равно закрылась, т.к. качество услуг осталось на примитивном уровне, а ценник с каждым годом становился все больше и больше. Клиенты просто поняли, что нет смысла платить приличные деньги хрен пойми за что. Тем не менее, владелец БИГа денег поднял очень даже неслабо.
Возможно, я эту самую маркетинговую функцию раньше так не жаловал именно потому, что в БИГе я никак ей не занимался. Да никто ей там не занимался. Мы с потоком обращений клиентов еле справлялись.
Таким образом, маркетинговая функция в нашем проекте по разработке программного комплекса «ИНТЕГРАЛ» явно провисала и перспектив на ближайшее время никаких не было. Я не хотел потерять такого хорошего программиста и даже переключил его на другую работу, надеясь, что, может быть, ситуация улучшится и он снова будет заниматься нашим ИТ-проектом. Он стал заниматься разработкой второй версии наших первых двух сайтов.
Время шло, а никаких улучшений не происходило. Наша программе продавалась, но объемы были очень маленькие. Возможностей для существенных вложений в продвижение и рекламу не было. Я понимал, что дальнейшее продолжение проекта будет приводить к еще большим затратам.
Пришло время для использования одного из методов принятия стратегических решениях. Речь идет о методе sunk costs (утопленные затраты). Суть вроде бы проста в теории, но на практике порой бывает очень сложно применить этот метод.
Согласно данному методу, при принятии решений о продолжении стратегического проекта в большей степени нужно опираться на оценку будущих перспектив, а не на фактические затраты и вложенные усилия. Затраты все равно уже не вернешь (из-за этого они и называются утопленными), поэтому не нужно на них ориентироваться. Прежде всего, нужно учитывать перспективы.
Как я уже отметил, в теории звучит логично, но на практике этот метод очень сложно применять с психологической точки зрения. Одно дело, когда пишешь об этом методе в книге или рассказываешь на семинаре, а другое дело – применяешь сам.
Мы столько сил (я уж молчу о деньгах) вложили в этот проект, а он оказался коммерчески не успешным. Рука не поднималась, чтобы его закрыть. Мы над ним работали более 6-ти лет.
Решение о закрытии данного ИТ-проекта до сих пор является самым тяжелым в моей бизнес-практике. Я и раньше уже применял методику sunk costs для закрытия других стратегических проектов, но в тех случаях я так сильно не переживал.
Например, в свое время мы закрыли наше издательское направление. Мы поняли, что это отдельный бизнес, которым нужно заниматься целенаправленно. Поэтому с тех пор сотрудничаем с издательством «Москва». Правда, теперь это издательство входит в наш совместный холдинг, но мы много лет сотрудничали с ним в качестве внешнего клиента.
С ИТ-направлением, видимо, примерно то же самое. Его также нужно рассматривать как отдельный бизнес, а не просто как одно из направлений деятельности. Может быть, в будущем наш холдинг займется и ИТ-бизнесом.
Я так подумал и понял, что, пожалуй, самым геморройным в моей жизни был проект «Жена» (см. статью «Самый крутой стратегический факап в моей жизни»). Вот только, к сожалению, здесь не применишь метод sunk costs в полной мере. Этот проект не только огромные бабки у меня сожрал (утопленные затраты), так он, сука, до сих пор продолжает их из меня вытаскивать.
Как говорится, текущая жена – это временно, а бывшая – это навсегда :)) Текущей у меня теперь нет, чтобы не было еще одной бывшей. Двойной гемор финансово я еще потяну, а вот морально – уже вряд ли :)).
Дело в том, что до сих пор многие компании ставят телегу впереди лошади. То есть они приступают к автоматизации, не проработав все организационно-методологические вопросы.
Нередко были такие случаи, когда к нам приезжали на открытые семинары по бюджетированию и управленческому учету и буквальное в первый же час спрашивали о том, какие программные продукты мы рекомендуем для автоматизации. Они утверждали, что основная проблема у них именно в отсутствии автоматизации.
В 100% случаев к концу семинара все задавальщики таких вопросов сидели с кислыми хлебальниками, поскольку понимали, что у них конь не валялся в плане бюджетирования и управленческого учета. Поэтому никакой, даже самый лучший в мире программный продукт им не поможет.
На таких семинарах-практикумах мы очень подробно рассматриваем следующие вопросы:
– цели и концепция бюджетирования и управленческого учета;
– модель (методика) бюджетирования и управленческого учета;
– управленческая учетная политика;
– регламент бюджетирования и управленческого учета;
– роль финансово-экономической службы в бюджетировании и управленческом учете;
– роль генерального директора в бюджетировании и управленческом учете;
– бюджетный комитет;
– технология постановки бюджетирования и управленческого учета;
– автоматизация бюджетирования и управленческого учета.
Кстати, подробнее о том, как проходят наши семинары-практикумы по данным темам, можно прочитать (или посмотреть видеоролики) на страницах одного из наших сайтов:
– самое эффективное обучение бюджетному управлению;
– самое эффективное обучение управленческому учету;
Таким образом, часть компаний, которые к нам обращались сразу за автоматизацией, нам удавалось убедить в том, что перед автоматизацией нужно разработать саму систему бюджетирования и управленческого учета, а потом уже переходить к автоматизации.
На самом деле такие обращения приводили не только к реализации проектов по постановке бюджетирования и управленческого учета. Дело в том, что мы всегда внедренческие проекты начинаем с постановки задачи, в ходе которой проводим диагностику компании.
Во-многих случаях выясняется, что в компании нет хорошо проработанной стратегии, да и механизма ее успешной реализации. Иными словами, нет системы стратегического управления. поэтому мы рекомендуем реализовать и проект по постановке стратегического менеджмента.
Некоторые компании к нам прислушиваются, а некоторые – нет. Одной из компаний, которая проигнорировала наши рекомендации, была федеральная сеть «Старик Хоттабыч». Была, потому что ее больше нет. Она закрылась примерно через год после того, как мы завершили проект по улучшению действующей системы бюджетирования и управленческого учета.
Зайдя на корпоративный сайт нашей Компании РиК (rik-company.ru) или сайт направления «Бюджетирование и управленческий учет» (bud-tech.ru) вы можете увидеть, что до сих пор в разделе «Продукты и услуги» есть раздел «Программный продукт» с описанием программного комплекса «ИНТЕГРАЛ». Мы его специально оставили, поскольку по-прежнему, часть клиентов по консалтингу мы получаем из тех компаний, которые сразу обращаются за автоматизацией.
В общем, если проект по разработке ПК «ИНТЕГРАЛ» оценивать только по деньгам, то он, безусловно, получится провальным. Я считаю, что помимо финансово-экономического, нужно оценивать и другие результаты данного проекта.
Выполняя этот проект, я прокачал свои скила в автоматизации управленческого учета и бюджетирования. Как я выше уже отметил, раньше я разрабатывал модели только в Excel. Теперь я научился это делать в программном продукте, работающем не со скалярными величинами, а с многомерными векторами.
Кроме того, я на практике изучил возможности применения OLAP-технологии для формирования управленческой отчетности. До этого я знал ее только в теории.
Также я получил опыт применения метода sunk costs в очень непростой ситуации. Как выше я уже написал, я и раньше применял метод утопленных затрат, но в тех ситуациях не было таких финансовых вложений, затрат времени и ожиданий результата. Например, нам пришлось закрыть новое маркетингово-сбытовое подразделение буквально через три месяца после начала его работы (см. статью «Создание отдела маркетинга и продаж»). Затраты были несущественные – только заработная плата, услуги связи и канцтовары. Здесь не было каких-то сильных переживаний. Решение было принято без колебаний и сожалений.
В случае в ИТ-проектом по разработке программного комплекса «ИНТЕГРАЛ» все было намного сложнее. В данного проекта были очень большие финансовые и временные затраты. К тому же осталось очень неприятный осадок от того, что не удалось достигнуть коммерческого успеха.
Дело даже не в деньгах. Нам удалось создать действительно очень качественный продукт, который во многом превосходил продукты конкурентов. Мы им проиграли не потому, что наш продукт хуже, а потому, что мы почти все вложили в R&D, сделав действительно очень качественный продукт, а у них львиная доля бюджета проекта ушла на маркетинг. Надеюсь, они хотя бы потом улучшили качество своего софта, ведь некоторые из них сейчас занимают лидирующие позиции на рынке автоматизации бюджетирования и управленческого учета, да и не только.
Если бы мы сделали какое-то фуфло, было бы не так обидно. Хотя, я бы не стал кому-то впаривать фуфло. Наверное, я какой-то неправильный предприниматель, но для меня важно наносить пользу клиентам, а не сбагривать им какую-то хрень по как можно более высокой цене. Видимо, со своим подходом я уже вряд ли когда-либо заработают хренову тучу бабла :)).
Итак, чисто с коммерческой точки зрения данный ИТ-проект оказался полностью провальным, но я не жалею о том, что все-таки попробовал его реализовать. Я помню, что еще до начала проекта один мой бывший коллега по группе БИГ предупреждал меня о том, что в такие проекты лучше не ввязываться без очень больших бюджетов.
Сейчас понимаю, что специализированные программы вряд ли будут приносить большие прибыли их разработчикам. Исключение составляет только обязаловка. Например, программы для сдачи внешней отчетности. Все понимают, о каких программных продуктах идет речь. Это программы, которые, по сути, навязываются государством. Скорее всего, кое-то в доле. Это стандартный российский схематоз :)).
На мой взгляд, в наше время, если и вкладываться в разработку программы для автоматизации компании, то это должны быть программы класса ERP (Enterprise Resource Planning). Вкладывать в какое-то узкоспециализированное направление, скорее всего, нет смысла. Может быть, когда-нибудь наша инвестиционно-консалтинговая группа МЭК и «замахнется на Вильяма нашего Шекспира».
Как я уже писал выше, когда-то мы отказались от издательского направления, но в итоге вернулись к нему, уже как к отдельному бизнесу. Может быть, и IT-бизнес замутим.
Это очень долгосрочный и затратный проект с учетом того, что зарплаты программистов достигли каких-то космических высот. Да и в маркетинг придется неслабо вложиться. Пока мы к такому проекту не готовы.
Кстати, у нас было в планах сделать из ПК «ИНТЕГРАЛ» что-то вроде ERP-системы. Помимо модулей «Бюджетирование» и «Управленческий учет» мы сделали модуль «CRM (Customer Relationship Management)», правда, до его продажи дело так и не дошло. Зато мы успели испытать этот модуль при реализации проекта по запуску маркетингово-сбытового отдела (см. статью «Создание отдела маркетинга и продаж»). Данный проект мы тоже закрыли (это еще один мой крутой факап), но сам модуль себя очень хорошо показал на практике.
Опять-таки, на тот момент времени наш модуль «CRM» был одним из самых лучших. Перед его созданием мы изучили то, что было на рынке, поэтому данное утверждение не является голословным.
Проект по созданию программного комплекса «ИНТЕГРАЛ»
До этого проекта у меня не было личного опыта в реализации ИТ-проектов. Я наблюдал за реализацией одного ИТ-проекта, когда работал в консалтинговой компании наемным сотрудником. Речь идет о консалтинговой группе БИГ, в которой я проработал 7 лет (с 1995-го по 2003-й год). Там ИТ-проект был реализовано с очень большой эффективностью и получился весьма коммерчески успешным.
Все началось с того, что сначала к нам на короткий бесплатный семинар по организационному проектированию приехали представители компании «Сибирский алюминий» (сейчас «Русский алюминий»). Как раз я проводил этот семинар. Тогда я еще только учился проводить семинары. Начинал именно с бесплатных, чтобы участники особых претензий не могли предъявить за не очень качественное проведение. Как говорится, на халяву и уксус сладкий.
Потом они заказали проведение корпоративного семинара, который проводил уже наш шеф. Семинар проводился в Красноярке. Я должен был лететь вместе с шефом, но я умудрился за несколько дней до вылета опоздать на работу на 15 минут и в качестве наказания меня сняли с этого проекта. Как мне потом рассказал коллега, который полетел вместо меня, это был чартерный рейс. В самолете из пассажиров были только представители компании, мой шеф и коллега, а также группа «Стрелки». Олды помнят, что
Через месяц после семинара у нас начался проект по организационной структуризации, в рамках которого была проведена не только организационно-методологическая работа, но и разработан программный продукт для моделирования организационной структуры. Я непосредственного участия в разработке ТЗ для программного продукта не принимал. Этим занимался мой коллега, который как раз летал на корпоративный семинар вместе со «Стрелками». Кстати, он так мне и не признался, гонялся ли он сам за этими «Стрелками» или нет. Все-таки он женатый был, поэтому зашифровался и ничего не рассказывал. Мало ли, вдруг как-то инфа и до жены дойдет.
Можно сказать, что этот проект для нас был одновременно и текущим, и проектом развития. Текущим -- потому что мы на нем заработали; развития -- потому что мы еще и создали актив (тот самый программный продукт), который в дальнейшем приносил нам дополнительную прибыль. Мы стали продавать этот программный продукт и как коробочное решение, и применяли его при реализации консалтинговых проектов по организационной структуризации компаний и групп.
Когда мой коллега, курировавший проект по разработке данного программного продукта, ушел из этой компании и запустил свой консалтинговый бизнес, то он как-то договорился с программистом и тот, уж не знаю на каких условиях, передал исходный код. Потом он существенно развил эту программу.
В общем, конкретно этот ИТ-проект мне показался совсем несложным. Поэтому, когда встал вопрос о реализации собственного ИТ-проекта, я посчитал, что ничего супер-рискованного в нем нет.
Разработка программного комплекса «ИНТЕГРАЛ»
Мы стали изучать уже имеющийся софт для автоматизации бюджетирования и управленческого учета. Я понимаю, что, мягко говоря, не совсем корректно как-то очернять конкурентов, но по крайней мере на тот момент времени (2005-й год) все, что тогда было на рынке, – это любое говнище. Поверьте, это я еще подбирал слова. Сразу оговорюсь, мы не изучали «тяжелые» системы, на которых сидит крупняк. Возможно, там эти модули реализованы не через задницу.
Мы понимали, что не можем ничего толкового посоветовать клиентам, поэтому постепенно пришли к пониманию того, что нам нужно разработать собственный софт под нашу методологию бюджетирования и управленческого учета.
Кстати, подробнее о разработке этих методик можно прочитать (или посмотреть видеоролики) на следующих страницах одного из наших сайтов:
– самая проработанная методика бюджетирования;
– самая проработанная методика управленческого учета.
Итак, было принято стратегическое решение о реализации ИТ-проекта по разработке собственного софта для автоматизации бюджетирования и управленческого учета. Начать мы, естественно, решили с разработки модуля «Управленческий учет» для автоматизации факта, поскольку автоматизировать планирование значительно сложнее.
Дело в том, что принципы и концепция планирования и учета существенно различаются. Концептуальная модель формирования фактической управленческой отчетности представлена на рисунке 1, а плановой – на рисунке 2. Подробнее об этом можно прочитать в книге «Эффективная система бюджетирования и управленческого учета. Практические советы и рекомендации».
После того, как мы разобрались с автоматизацией фактического управленческого учета, перешли к автоматизации модели планирования. Честно говоря, на решение данной задачи у нас ушло больше времени.
Мы решили, что будем придерживаться стратегии гибкой автоматизации, когда все необходимые настройки модели и регламента бюджетирования и управленческого учета осуществляются не программистом (изменение программного кода), а экономистом с помощью специального конструктора (или мастера). Если человек знает методологию бюджетирования и управленческого учета, он должен иметь возможность настроить автоматизированную модель и регламент без помощи программистов. Поэтому мы стали придерживаться логики, представленной на рисунке 3.
Перед тем, как заниматься автоматизацией, нужно сначала определиться с показателями и с форматами фактической и плановой отчетности. Затем нужно разработать модель (методику) формирования каждого показателя в фактической и плановой отчетности. До этого момента еще никакой автоматизации вообще нет.
Дальше возможны два варианта: жесткая и гибкая автоматизация. В первом случае программистам передается ТЗ с описанием модели формирования плановой и фактической отчетности. Программисты сами занимаются настройкой этих модели через написание кода. Соответственно, если что-то нужно будет поменять, придется каждый раз обращаться к программистам. Каждое вмешательство в код увеличивает риски ошибок. Причем не все ошибки сразу могут проявиться.
Гибкая стратегия автоматизации не подразумевает программирования. Настройка модели осуществляется с использованием вышеупомянутого конструктора (мастера) для настройки модели. Понятно, что сам конструктор построен на основе определенной модели, которая уже не меняется. Точнее говоря, ее можно изменить, но для этого уже придется менять код.
Примеры настройки методики (модели) учета и планирования представлены на рисунках 4 и 5.
Таким образом, нам удалось разработать программу, в которой вся модель и регламент бюджетирования и управленческого учета настраивались экономистами без привлечения ИТ-специалистов и тем более программистов. Участие ИТ-специалиста требовалось только для установки программы и базы данных. В итоге нам удалось разработать программный продукт, соответствующий нашей технологии управленческого учета и бюджетирования.
Поскольку к нам за автоматизацией обращались не только компании, но и холдинги, мы реализовали возможность настройки консолидированной модели.
На самом деле необходимость консолидации может возникнуть и у одной компании, если она использует несколько юрлиц. В таком случае нужно будет консолидировать фактические данные из разных баз. Для этого должна быть реализована возможность настройки такой модели.
Стоит отметить, что для формирования самих отчетов мы использовали многомерный иерархический OLAP-куб. Мягко говоря, не во всех программах реализована такая возможность.
Это особенно актуально, когда у компании возникает потребность в детализации отчетности. В таком случае с помощью OLAP-куба можно один и тот же отчет выводить в различных вариантах в зависимости от набора аналитик у каждого показателя отчета.
Вынужден признаться, что я не сразу сориентировался в многомерной отчетности. Пришлось учиться многомерному мышлению, поскольку до этого я разрабатывал финансово-экономические модели только в Excel.
В электронных таблицах в основном работаешь со скалярными величинами. Проще говоря, настраиваешь формулу, связывая между собой ячейки.
В нашем программном продукте при разработке модели приходится работать с векторами с максимальной размерностью, равной трем. То есть каждый показатель (строка отчета) может иметь от нуля (тогда это скаляр) до трех аналитик. Например, выручка от реализации может детализироваться по продуктам, каналам сбыта и филиалам.
Когда связываешь формулами скалярные величины всегда получается скалярная величина. А когда проделываешь то же самое с векторами, результат получается неоднозначным. Поэтому нам пришлось разработать свои правила вычисления.
Бывают очевидные ситуации. Например, из выручки, детализированной по продуктам (одномерный вектор), вычитается себестоимость, тоже детализированная по продуктам. В этом случае результатом тоже будет одномерный вектор -- валовая прибыль с детализацией по продуктам.
Но пользователь программного продукта может настроить какую угодно формулу и не обратить внимание на размерность. Например, может из выручки, детализированной по продуктам, вычесть операционные расходы, детализированные по статьям затрат. Оба показатели являются одномерными векторами, но аналитики то у них не совпадают.
Короче говоря, при работе с многомерными объектами возникает много всяких нюансов, которые нужно учитывать и в которые нужно въехать.
Нам очень повезло с программистом. Очень толковый попался. Причем он сам генерировал интересные идеи, которые реализовывал после согласования с нами.
На момент разработки нашей программы и до закрытия проекта это было очень крутое решение, значительно превосходившее аналоги. Еще раз отмечу, что с большими ERP-системами мы не конкурировали.
Самое тяжелое решение в бизнесе
Честно говоря, в тот момент времени не было особой возможности заниматься маркетингом. Сайты, к сожалению, пока еще не были раскручены (подробнее об этой моей стратегической ошибке написано в статье «Стратегические косяки в создании и продвижении сайтов»). Основным источником клиентов тогда были книги. Клиентов, приходивших по книгам, хватало для семинаров и консалтинговых проектов, но для того, чтобы зарабатывать на продаже «коробок», поток должен был быть намного больше.
Мы пробовали заниматься и активными продажами, но умудрились запустить этот проект прямо в самый разгар кризиса, поэтому его пришлось вскоре закрыть (подробнее об этом написано в статье «Создание отдела маркетинга и продаж»).
Вкладывать значительные средства в оперативную рекламу тогда не было возможности, поскольку, во-первых, после кризиса мы еще не восстановились, во-вторых, я женился (это самая большая стратегическая ошибка в моей жизни), в-третьих, родился первый ребенок, в-четвертых, влез в ремонт дома, а это, как оказалось, намного более проблематичнее и затратнее, чем ремонт квартиры (даже если квартира такого же метража). После этого ремонта я даже написал книгу для тех, кто хочет сохранить время, деньги и нервы при ремонте. Она называется «Наилучший ремонт квартир, таунхаусов и домов. Как сохранить деньги, время и нервы».
Из-за того, что все деньги под ноль уходили на ремонт и семью, я даже перестал переиздавать старые книги и издавать новые. Поэтому и данный стратегический маркетинговый инструмент стал приносить меньше клиентов.
Я еще раз убедился в том, что больше всех зарабатывают те, кто вкладывается в маркетинг, а не в разработку продукта (R&D). По крайней мере в нашей стране это так.
У меня ведь было два наглядных примера. Как выше я уже написал, в группе БИГ я проработал с 1995-го по 2003-й, но примерно на год уходил в другую консалтинговую компанию, а потом вернулся. В плане развития своего потенциала разработчика и производственника за год в этой компании я продвинулся намного больше, чем за 7 лет в БИГе (подробнее о составляющих рабочего потенциала человека и о том, как его нужно развивать, написано в книге «Максимизация личного заработка: стратегия и конкретный план»). Сотрудники этой небольшой консалтинговой компании как эксперты были несопоставимо более продвинутыми, чем консультанты группы БИГ, но с маркетингом у них было, мягко говоря, не все в порядке.
В группе БИГ, наоборот, не было отбоя от клиентов, правда, до поры до времени. Просто владелец этой компании очень грамотно вложился в маркетинг. Причем вложения его составили 0 рублей 0 копеек. В итоге компания все-равно закрылась, т.к. качество услуг осталось на примитивном уровне, а ценник с каждым годом становился все больше и больше. Клиенты просто поняли, что нет смысла платить приличные деньги хрен пойми за что. Тем не менее, владелец БИГа денег поднял очень даже неслабо.
Возможно, я эту самую маркетинговую функцию раньше так не жаловал именно потому, что в БИГе я никак ей не занимался. Да никто ей там не занимался. Мы с потоком обращений клиентов еле справлялись.
Таким образом, маркетинговая функция в нашем проекте по разработке программного комплекса «ИНТЕГРАЛ» явно провисала и перспектив на ближайшее время никаких не было. Я не хотел потерять такого хорошего программиста и даже переключил его на другую работу, надеясь, что, может быть, ситуация улучшится и он снова будет заниматься нашим ИТ-проектом. Он стал заниматься разработкой второй версии наших первых двух сайтов.
Время шло, а никаких улучшений не происходило. Наша программе продавалась, но объемы были очень маленькие. Возможностей для существенных вложений в продвижение и рекламу не было. Я понимал, что дальнейшее продолжение проекта будет приводить к еще большим затратам.
Пришло время для использования одного из методов принятия стратегических решениях. Речь идет о методе sunk costs (утопленные затраты). Суть вроде бы проста в теории, но на практике порой бывает очень сложно применить этот метод.
Согласно данному методу, при принятии решений о продолжении стратегического проекта в большей степени нужно опираться на оценку будущих перспектив, а не на фактические затраты и вложенные усилия. Затраты все равно уже не вернешь (из-за этого они и называются утопленными), поэтому не нужно на них ориентироваться. Прежде всего, нужно учитывать перспективы.
Как я уже отметил, в теории звучит логично, но на практике этот метод очень сложно применять с психологической точки зрения. Одно дело, когда пишешь об этом методе в книге или рассказываешь на семинаре, а другое дело – применяешь сам.
Мы столько сил (я уж молчу о деньгах) вложили в этот проект, а он оказался коммерчески не успешным. Рука не поднималась, чтобы его закрыть. Мы над ним работали более 6-ти лет.
Решение о закрытии данного ИТ-проекта до сих пор является самым тяжелым в моей бизнес-практике. Я и раньше уже применял методику sunk costs для закрытия других стратегических проектов, но в тех случаях я так сильно не переживал.
Например, в свое время мы закрыли наше издательское направление. Мы поняли, что это отдельный бизнес, которым нужно заниматься целенаправленно. Поэтому с тех пор сотрудничаем с издательством «Москва». Правда, теперь это издательство входит в наш совместный холдинг, но мы много лет сотрудничали с ним в качестве внешнего клиента.
С ИТ-направлением, видимо, примерно то же самое. Его также нужно рассматривать как отдельный бизнес, а не просто как одно из направлений деятельности. Может быть, в будущем наш холдинг займется и ИТ-бизнесом.
Я так подумал и понял, что, пожалуй, самым геморройным в моей жизни был проект «Жена» (см. статью «Самый крутой стратегический факап в моей жизни»). Вот только, к сожалению, здесь не применишь метод sunk costs в полной мере. Этот проект не только огромные бабки у меня сожрал (утопленные затраты), так он, сука, до сих пор продолжает их из меня вытаскивать.
Как говорится, текущая жена – это временно, а бывшая – это навсегда :)) Текущей у меня теперь нет, чтобы не было еще одной бывшей. Двойной гемор финансово я еще потяну, а вот морально – уже вряд ли :)).
Результаты проекта и выводы
Дело в том, что до сих пор многие компании ставят телегу впереди лошади. То есть они приступают к автоматизации, не проработав все организационно-методологические вопросы.
Нередко были такие случаи, когда к нам приезжали на открытые семинары по бюджетированию и управленческому учету и буквальное в первый же час спрашивали о том, какие программные продукты мы рекомендуем для автоматизации. Они утверждали, что основная проблема у них именно в отсутствии автоматизации.
В 100% случаев к концу семинара все задавальщики таких вопросов сидели с кислыми хлебальниками, поскольку понимали, что у них конь не валялся в плане бюджетирования и управленческого учета. Поэтому никакой, даже самый лучший в мире программный продукт им не поможет.
На таких семинарах-практикумах мы очень подробно рассматриваем следующие вопросы:
– цели и концепция бюджетирования и управленческого учета;
– модель (методика) бюджетирования и управленческого учета;
– управленческая учетная политика;
– регламент бюджетирования и управленческого учета;
– роль финансово-экономической службы в бюджетировании и управленческом учете;
– роль генерального директора в бюджетировании и управленческом учете;
– бюджетный комитет;
– технология постановки бюджетирования и управленческого учета;
– автоматизация бюджетирования и управленческого учета.
Кстати, подробнее о том, как проходят наши семинары-практикумы по данным темам, можно прочитать (или посмотреть видеоролики) на страницах одного из наших сайтов:
– самое эффективное обучение бюджетному управлению;
– самое эффективное обучение управленческому учету;
Таким образом, часть компаний, которые к нам обращались сразу за автоматизацией, нам удавалось убедить в том, что перед автоматизацией нужно разработать саму систему бюджетирования и управленческого учета, а потом уже переходить к автоматизации.
На самом деле такие обращения приводили не только к реализации проектов по постановке бюджетирования и управленческого учета. Дело в том, что мы всегда внедренческие проекты начинаем с постановки задачи, в ходе которой проводим диагностику компании.
Во-многих случаях выясняется, что в компании нет хорошо проработанной стратегии, да и механизма ее успешной реализации. Иными словами, нет системы стратегического управления. поэтому мы рекомендуем реализовать и проект по постановке стратегического менеджмента.
Некоторые компании к нам прислушиваются, а некоторые – нет. Одной из компаний, которая проигнорировала наши рекомендации, была федеральная сеть «Старик Хоттабыч». Была, потому что ее больше нет. Она закрылась примерно через год после того, как мы завершили проект по улучшению действующей системы бюджетирования и управленческого учета.
Зайдя на корпоративный сайт нашей Компании РиК (rik-company.ru) или сайт направления «Бюджетирование и управленческий учет» (bud-tech.ru) вы можете увидеть, что до сих пор в разделе «Продукты и услуги» есть раздел «Программный продукт» с описанием программного комплекса «ИНТЕГРАЛ». Мы его специально оставили, поскольку по-прежнему, часть клиентов по консалтингу мы получаем из тех компаний, которые сразу обращаются за автоматизацией.
В общем, если проект по разработке ПК «ИНТЕГРАЛ» оценивать только по деньгам, то он, безусловно, получится провальным. Я считаю, что помимо финансово-экономического, нужно оценивать и другие результаты данного проекта.
Выполняя этот проект, я прокачал свои скила в автоматизации управленческого учета и бюджетирования. Как я выше уже отметил, раньше я разрабатывал модели только в Excel. Теперь я научился это делать в программном продукте, работающем не со скалярными величинами, а с многомерными векторами.
Кроме того, я на практике изучил возможности применения OLAP-технологии для формирования управленческой отчетности. До этого я знал ее только в теории.
Также я получил опыт применения метода sunk costs в очень непростой ситуации. Как выше я уже написал, я и раньше применял метод утопленных затрат, но в тех ситуациях не было таких финансовых вложений, затрат времени и ожиданий результата. Например, нам пришлось закрыть новое маркетингово-сбытовое подразделение буквально через три месяца после начала его работы (см. статью «Создание отдела маркетинга и продаж»). Затраты были несущественные – только заработная плата, услуги связи и канцтовары. Здесь не было каких-то сильных переживаний. Решение было принято без колебаний и сожалений.
В случае в ИТ-проектом по разработке программного комплекса «ИНТЕГРАЛ» все было намного сложнее. В данного проекта были очень большие финансовые и временные затраты. К тому же осталось очень неприятный осадок от того, что не удалось достигнуть коммерческого успеха.
Дело даже не в деньгах. Нам удалось создать действительно очень качественный продукт, который во многом превосходил продукты конкурентов. Мы им проиграли не потому, что наш продукт хуже, а потому, что мы почти все вложили в R&D, сделав действительно очень качественный продукт, а у них львиная доля бюджета проекта ушла на маркетинг. Надеюсь, они хотя бы потом улучшили качество своего софта, ведь некоторые из них сейчас занимают лидирующие позиции на рынке автоматизации бюджетирования и управленческого учета, да и не только.
Если бы мы сделали какое-то фуфло, было бы не так обидно. Хотя, я бы не стал кому-то впаривать фуфло. Наверное, я какой-то неправильный предприниматель, но для меня важно наносить пользу клиентам, а не сбагривать им какую-то хрень по как можно более высокой цене. Видимо, со своим подходом я уже вряд ли когда-либо заработают хренову тучу бабла :)).
Итак, чисто с коммерческой точки зрения данный ИТ-проект оказался полностью провальным, но я не жалею о том, что все-таки попробовал его реализовать. Я помню, что еще до начала проекта один мой бывший коллега по группе БИГ предупреждал меня о том, что в такие проекты лучше не ввязываться без очень больших бюджетов.
Сейчас понимаю, что специализированные программы вряд ли будут приносить большие прибыли их разработчикам. Исключение составляет только обязаловка. Например, программы для сдачи внешней отчетности. Все понимают, о каких программных продуктах идет речь. Это программы, которые, по сути, навязываются государством. Скорее всего, кое-то в доле. Это стандартный российский схематоз :)).
На мой взгляд, в наше время, если и вкладываться в разработку программы для автоматизации компании, то это должны быть программы класса ERP (Enterprise Resource Planning). Вкладывать в какое-то узкоспециализированное направление, скорее всего, нет смысла. Может быть, когда-нибудь наша инвестиционно-консалтинговая группа МЭК и «замахнется на Вильяма нашего Шекспира».
Как я уже писал выше, когда-то мы отказались от издательского направления, но в итоге вернулись к нему, уже как к отдельному бизнесу. Может быть, и IT-бизнес замутим.
Это очень долгосрочный и затратный проект с учетом того, что зарплаты программистов достигли каких-то космических высот. Да и в маркетинг придется неслабо вложиться. Пока мы к такому проекту не готовы.
Кстати, у нас было в планах сделать из ПК «ИНТЕГРАЛ» что-то вроде ERP-системы. Помимо модулей «Бюджетирование» и «Управленческий учет» мы сделали модуль «CRM (Customer Relationship Management)», правда, до его продажи дело так и не дошло. Зато мы успели испытать этот модуль при реализации проекта по запуску маркетингово-сбытового отдела (см. статью «Создание отдела маркетинга и продаж»). Данный проект мы тоже закрыли (это еще один мой крутой факап), но сам модуль себя очень хорошо показал на практике.
Опять-таки, на тот момент времени наш модуль «CRM» был одним из самых лучших. Перед его созданием мы изучили то, что было на рынке, поэтому данное утверждение не является голословным.
