Индивидуальность по рецепту
Николай Комлев. Спасибо журналу за очередной "круглый стол", который становится уже регулярно проводимым на ведущих выставках ИТ-направления. Когда формировались темы данного мероприятия и предлагались вопросы для обсуждения, возникло ощущение, что основной вектор этой темы до боли знаком. В том или ином виде похожие вопросы эпизодически поднимались примерно с середины 90-х. Мы тогда тоже обсуждали, каким путём идти разработчикам: то ли делать систему в виде максимально гибкого конструктора, чтобы любой внедренец или грамотный бухгалтер мог её под себя настроить, то ли делать закрытую для пользователя, но максимально готовую к практическому применению, подстраиваемую в некоторых небольших пределах, тиражируемую отраслевую или специализированную систему, склоняя пользователя к тому, чтобы он перестроил свои процессы под предлагаемую систему. И когда сейчас эта тема была предложена, вначале показалось, что она как бы старая. Потом решили, что она не старая - она вечная. А о вечном можно действительно говорить много, и если вопрос остаётся актуальным, значит, здесь есть предмет обсуждения, тем более что со временем появляются варианты, какие-то разные оттенки.
А дальше вот что. Если классифицировать бизнес-процессы как производственные (где преобладают операции с материальными активами) и управленческие (преобладают операции с нематериальными активами), то можно говорить о типовых производственных бизнес-процессах для российской и западной моделей бизнеса (таких может быть до 70 % от общего количества). Рассматривать типовые управленческие бизнес-процессы вряд ли целесообразно в силу различия правовых систем и нормативно-законодательной базы в России и за рубежом. Мало того, даже внутри России стандартизация управленческих бизнес-процессов вряд ли возможна из-за существенного различия нематериальных активов в отечественных организациях, их стратегической и тактической нестабильности, включая лиц на предприятии заказчика, принимающих решение о реинжиниринге.
Иначе говоря, для исполнителя задача сегодня должна стоять как "проект под клиента". Заказчик в этом случае получает требуемую ему бизнес-модель, которая, как он считает, должна обеспечить ему конкурентное преимущество, и не ломает голову над выбором конкретных программных продуктов.
Мы более пятнадцати лет разрабатывали эти системы. Всё-таки бизнес, опыт бизнеса и опыт тех бизнес-процессов, которые на предприятиях внедряли, весь собран и отражён в хороших системах, в том числе и в наших. И тогда на том же производственном предприятии их часто рассматривают не только как автоматизированные системы, созданные по принципу "сделайте мне то и внедрите так, как я хочу". Они уже становятся учебником по бизнесу. Да, и такое тоже бывает: "а вот покажите, как другие работают". А как другие работают - это уже заложено, "прошито" в программах. И очень часто бывает, что, посмотрев, как это можно делать, меняют свои бизнес-процессы, причём никто не заставляет их это делать насильно, типа "или так, или никак". Сами меняют, потому что признают: да, это более эффективно. Поэтому тут я с Сергеем Проскуриным согласен, что вот таких прописанных, чётких, стандартных бизнес-процессов - их, наверное, нет нигде. Хотя предприятия принадлежат одной отрасли, более или менее одинаковы, но работают они по-разному. Да, основные бизнес-процессы отрасли более или менее похожи, но всё равно приходится в деталях многое подстраивать. Естественно, надо подстраивать под конкретное предприятие. Если, к примеру, возьмём 20 хлебозаводов, то на 80 % у них всё может быть и одинаково, а остальное приходится от предприятия к предприятию дорабатывать, подстраивать.
Реплика из зала. А что такое бизнес-процессы на уровне управления? Пример, пожалуйста, приведите.
Николай Комлев. Так, давайте всё же по очереди.
Вот Игорь Якобсон говорил о бизнес-процессе с точки зрения ведения документооборота. Каждый сам организует на своём предприятии внутренний документооборот, который также является бизнес-процессом. Который влияет на эффективность этого предприятия. Который может быть автоматизирован. И потому-то тема эта на самом деле очень интересная, как мне кажется. То направление, которое я представляю, - это "клиента под проект". Мы пошли по конкретному пути: мы разрабатываем, как можем, максимально полное решение для определённой отрасли, клиент его анализирует, и, если оно ему подходит, он его выбирает и у себя использует. Тем самым у него, безусловно, минимизируются все затраты по внедрению, надёжный продукт получает и т. д. Ну, естественно, это не охватывает всех клиентов. Если приходит ко мне клиент и говорит "а я вот хочу это, но только как у меня", то я отвечаю: "Извини, дорогой, это не ко мне. Для этого, скажем, есть "Интеллект-Сервис", "ТБ.Корпорация" или много других компаний, которые делают проект под конкретного клиента". И мне казалось, что именно эта альтернатива высвечена и важна в этой теме "круглого стола".
Николай Комлев. Вот прямо с этого момента мы плавно переходим на вопросы второго раздела. Получается, что для успеха необходимо согласование интересов сторон, взаимопроникновение в технологии, поэтому какая-то взаимная настройка неизбежна, так? Давайте поговорим на вторую тему.
Там работали специалисты, какие-то специальные отделы, считали, пытались стандартизировать и оптимизировать процессы, как мы это теперь пытаемся делать каждый для себя и кто во что горазд. Но государство решило, что это всё не годится и никому не нужно. И поэтому оно, как обычно, разрушило старую систему управления, не построив новой. А вот моё личное мнение по поводу "проекта - не проекта": если сейчас на элементарное торговое предприятие приехать и сказать: "Знаете, мы вам поставим вот такую чудесную, прямо-таки волшебную систему некоего западного разработчика. Только вот вы свои бизнес-процессы измените, так как они у вас уже устарели. И пойдут у вас дела просто шоколадно". Я думаю, что после этого всё элементарно рухнет.
Сергей Проскурин. Вот именно, наконец-то у вас это прозвучало: именно "вспомогательную", а то можно подумать, что чуть ли не вы сами управляли этими предприятиями.
Сергей Проскурин. Кстати, я могу привести такую статистику. Наша система "ЛокОФФИС" начала продаваться с 1992 года. Значит, с этого года один "Крокус" пока что уцелел, хотя было продано тогда 18 систем. В 1993-м тоже единицы уцелели. Вот в 1995-м живут уже побольше, кое-что осталось...
Владимир Пичугин. То, что сказал Сергей Проскурин, - это, мне кажется, больше было характерно для тех массовых бухгалтерских программ второй половины 1990-х годов, когда программы покупались в основном главным бухгалтером и внедрялись в бухгалтерии. Если раньше был подход "пусть бухгалтер сам выберет, с какой ему системой удобнее работать", то сейчас тенденция пошла иная: нужны уже управленческие решения, нужна комплексная система управления предприятием, бизнесом. Сейчас решения всё больше и больше принимаются первыми лицами. Внедряются крупные системы, которые помогают управлять многими подразделениями, деятельностью всей компании. И, естественно, принимают решения уже на гораздо более высоком уровне - чем дальше, тем больше: это решается на уровне финансового директора, генерального директора, президента фирмы и т. д.
Кстати, чем больше масштаб проекта, тем больше и сроки. Мы должны быть уверены, что через эти полтора года у нас не изменится внешняя среда, не изменится потребность в новой модели управления. Но в наших сегодняшних условиях такое нереально. Я этим летом изучала опыт заводов Toyota, их системы управления. Вообще-то, я сама по сути бывшая программистка, "айтишница", и мне всегда казалось, что интегрированные системы управления - это гораздо лучше, чем какая-то лоскутная автоматизация. Вот почему меня очень удивил подход этой корпорации в части автоматизации. Поразило то, что последние 30 лет здесь принципиально не берутся внедрять большие интегрированные системы. И это Toyota, которая является лидером в автомобилестроении, именно по производству: у них самая низкая себестоимость производства и самая совершенная система управления; они не стремятся всё делать сами - у них тысячи субподрядчиков, поставщиков, и just-in-time у них на деле реализован, а не на словах. Более того, они берут свою модель управления, которую в Японии отлаживали в течение 50 лет, и переносят свои производства в Америку и пусть не за 5 лет, а за 10, но реализуют похожие и очень эффективные системы управления.
Я, как мультивендорщик, неплохо знакомый с основными лидирующими российскими системами, старейший соратник этого клуба, могу высказать определённое мнение, не привязанное к какой-либо платформе и не лоббирующее ничьих интересов.
Алексей Нестеров. Стоимость крупной системы по большей части является основополагающим критерием. Руководство определяет, какие у него цели: увеличить капитализацию, выйти на IPO - это один выбор. Или в течение года решить актуальный вопрос с незавершёнкой, с планированием производства, прикинуть, где оно деньги потеряет, - это может быть другой выбор. От этого может зависеть и выбор платформы, её стоимость и сроки внедрения. Вот после этого идёт как раз выбор консультанта. Это может быть консультант мультивендорный, может быть одновендорный. Уже здесь, на этом этапе, происходит выбор его компетенции.
Николай Дерябин: Можно пару слов сказать в качестве представителя заказчика? Тут будут затронуты вопросы и второго, и четвёртого раздела. В принципе заказчику важно что? Чтобы был достигнут конкретный результат. И вот когда речь идёт о перспективах, которые должны просматриваться и закладываться уже сейчас, то представители тех же американских IBM, InterSystem говорят, что в их договорах предполагается заложить (пока этого ещё нет) принцип конкретной реализации бизнес-модели, приводящий к положительному результату (эффекту). Если эффект не достигается, деньги возвращаются или не выплачиваются. Вот таким образом они предлагают строить договорные отношения.
Особенности автоматизации:
проект под клиента или клиента под проект?.
"Круглый стол" под таким названием, организованный редакцией журнала "Бухгалтер и компьютер" (Издательский дом "Бухгалтерия и банки"), прошёл в рамках выставки SofTool-2005.
Предлагаем вам материал по выступлениям участников данного мероприятия. В качестве ведущего мероприятия традиционно выступил исполнительный директор ассоциации АП КИТ Николай Комлев.
Когда заказчик собирается автоматизировать у себя на предприятии учёт, управление, производство, документооборот и т. д., то он обязательно обращает внимание на то, какой опыт разработки и внедрения стоит за плечами тех или иных подрядчиков. Последние же, в свою очередь, предлагают клиентам некие готовые решения, схемы, типовые рецепты как по технологии автоматизации, так и по организации собственно бизнеса, отработанные на других клиентах (в том числе западных).
Эти технологии призваны вооружить пользователей эффективным ИТ-инструментом, глубиной анализа, скоростью реакции на изменения рынка, информативностью и подготовленностью управляющих решений, т. е. в принципе вроде бы должны обеспечивать конкурентные преимущества. Но, как показывают опыт и объективная статистика, часть проектов по тем или иным причинам оканчивается неудачей, принося клиентам разочарования и убытки.
В чём причина? Может, надо было не настаивать так упорно на своём уникальном видении реализации проекта перед другой стороной, а согласиться с предлагаемым уже отработанным типовым вариантом. Или как раз наоборот - не брать типовое решение, а отстаивать своё. Или не стоило безоглядно доверяться именитым внешним консультантам.
В общем, как всегда, остаёмся с вопросом: кто теперь виноват и что дальше делать?
В общем, как всегда, остаёмся с вопросом: кто теперь виноват и что дальше делать?
Итак, что перспективнее, правильнее при создании и внедрении ИТ-проектов - "подгонять" бизнес-процессы клиентов под стандарты, заложенные в системе автоматизации, или переделывать саму систему под уникальные (иногда даже "кривые") бизнес-процессы клиента?
Как сегодня обстоят дела в этом направлении автоматизации?
Можно ли унифицировать, типизировать какие-то процессы в ведении отечественного бизнеса, в управлении и пр.?
В каких отраслях это проще сделать?
Понятно, что таким образом можно облегчить процесс разработки задач автоматизации и внедрения проекта, а значит, снизить затраты на автоматизацию. Имеются ли сегодня так называемые госстандарты в этой области и как влияет государство на эти процессы?
Насколько в наших специфических экономических и правовых условиях интересен мировой опыт?
Насколько такой типовой подход приемлем для российского рынка и сегодняшнего состояния экономики, насколько с ним соглашаются стороны (разработчики и заказчики)?
Вот примерный круг вопросов, который поднимался и обсуждался на "круглом столе".
Сегодня массовость и тираж, индустриальные подходы всё более преобладают на рынке, вытесняя фирмы, занимающиеся индивидуальными проектами. Поэтому нередко предприятия (ИТ-потребители) испытывают некоторое давление со стороны разработчиков и автоматизаторов, когда им навязывают некие подходы: "вот у нас так, это сегодня передовые мировые тенденции, с нами работают тысячи пользователей - и всё нормально; не хотите - не берите".
Известно, что сегодня ведущие ИТ-компании, имеющие немалый опыт работы на рынке, всё чаще предлагают потребителям типовые проекты, некие стандарты, под которые клиент нередко должен перестраивать привычную организацию документооборота, ведения учёта и даже - ведения бизнеса, управления им.
Хорошо это или плохо и в каких случаях вариант такого подхода будет оправдан?
Хорошо это или плохо и в каких случаях вариант такого подхода будет оправдан?
Какие варианты предлагаются поставщиками ИТ?
Кто в конечном счёте отвечает за результаты таких подходов и решений - консультанты, поставщики, клиенты?
Как на это смотрят участники процесса с той и другой стороны?
Ниже мы приводим темы, которые обсуждались в первой части мероприятия, посвящённой бизнес-процессам как основе формальной модели предприятия.
Количество типовых бизнес-процессов постоянно растёт или есть тенденция к стабилизации и возможности их стандартизации?
Существуют ли вообще "стандарты" бизнес-процессов, возможна ли их разработка на перспективу?
Роль МСФО и прочих стандартов учёта в типологизации бизнес-процессов. Укладывается ли специфика российского бизнеса в западные модели ведения бизнеса, типовые для "них" бизнесс-процессы?
Как сильно влияют на бизнес-процессы разные правовые системы (западная - российская), нормативно-законодательные базы?
Николай Комлев. Спасибо журналу за очередной "круглый стол", который становится уже регулярно проводимым на ведущих выставках ИТ-направления. Когда формировались темы данного мероприятия и предлагались вопросы для обсуждения, возникло ощущение, что основной вектор этой темы до боли знаком. В том или ином виде похожие вопросы эпизодически поднимались примерно с середины 90-х. Мы тогда тоже обсуждали, каким путём идти разработчикам: то ли делать систему в виде максимально гибкого конструктора, чтобы любой внедренец или грамотный бухгалтер мог её под себя настроить, то ли делать закрытую для пользователя, но максимально готовую к практическому применению, подстраиваемую в некоторых небольших пределах, тиражируемую отраслевую или специализированную систему, склоняя пользователя к тому, чтобы он перестроил свои процессы под предлагаемую систему. И когда сейчас эта тема была предложена, вначале показалось, что она как бы старая. Потом решили, что она не старая - она вечная. А о вечном можно действительно говорить много, и если вопрос остаётся актуальным, значит, здесь есть предмет обсуждения, тем более что со временем появляются варианты, какие-то разные оттенки.Чтобы иметь возможность высказаться и выслушать по возможности всех желающих, предлагаю говорить коротко и конкретно, в соответствии с той частью вопросов, которые в данный момент обсуждаются. Собственно, предлагаю начать с первой части, с вопросов первого раздела.
О бизнес-процессах как основы формальной модели.
Можно ли сказать, что за последние годы как-то устоялось количество бизнес-процессов; стали ли они более или менее систематизируемыми?
Можно ли хоть на какой-то момент остановиться: вот они все более или менее известны, в принципе заложены в системе, их можно выбрать (скажем, галочками), посчитать - эти, эти, эти, - и вот уже система готова к использованию, и не нужно каждый раз чуть ли не с нуля начинать вести проект, разработку под конкретного клиента. Или это такой бесконечный процесс.
О бизнес-процессах как основы формальной модели.
Можно ли сказать, что за последние годы как-то устоялось количество бизнес-процессов; стали ли они более или менее систематизируемыми?
Можно ли хоть на какой-то момент остановиться: вот они все более или менее известны, в принципе заложены в системе, их можно выбрать (скажем, галочками), посчитать - эти, эти, эти, - и вот уже система готова к использованию, и не нужно каждый раз чуть ли не с нуля начинать вести проект, разработку под конкретного клиента. Или это такой бесконечный процесс.
Николай Дерябин (президент Фонда поддержки ИТ в авиационной и ракетно-космической отрасли, советник начальника Управления авиационной промышленности по ИТ). Может, сначала есть смысл сказать, что понимается под бизнес-процессом?
Кроме фонда поддержки ИТ в авиационно-космической отрасли я представляю ещё Федеральное агентство по промышленности, поэтому здесь говорю со стороны заказчика. Сегодня в оборонном комплексе эти вопросы широко и много обсуждаются, этому направлению опять начинают уделять внимание.
Прежде чем приступить к обсуждению темы "круглого стола", в целях одинакового толкования основных терминов имеет смысл как-то сформулировать некоторые базовые понятия, о которых далее будет идти речь, - такие как процесс, реинжиниринг и конкурентоспособность. К сожалению, ни в вузах не дают чётких определений, ни на предприятиях нет одинакового понимания этих базовых категорий. Вот как они определяются в наших, российских стандартах.
Процесс: совокупность последовательно и (или) параллельно выполняемых операций, преобразующих материальные и (или) нематериальные активы в соответствующие активы с другими свойствами.
Если вы следили за публикациями 2004-2005 годов в журнале "БиК", то это не должно вызвать непонимания, поскольку материальные и нематериальные активы как раз и характеризуют уровень развития общества и соответственно его место в мире. В информационном обществе около 80 % представляют собой нематериальные активы. В капитализации фирмы или капитализации продукта только порядка 20 % - материальные. Эти представления как раз говорят о многом.
Реинжиниринг: реструктуризация бизнес-процессов с целью их оптимизации по критерию максимума конкурентного преимущества.
Конкурентоспособность продукции: степень удовлетворённости потребностей клиента со стороны поставщика в качестве, стоимости, сроках поставки товара (или оказания услуги) и сопутствующих этому товару услугах (или сервисного обслуживания). Это мы дали общие определения.
А дальше вот что. Если классифицировать бизнес-процессы как производственные (где преобладают операции с материальными активами) и управленческие (преобладают операции с нематериальными активами), то можно говорить о типовых производственных бизнес-процессах для российской и западной моделей бизнеса (таких может быть до 70 % от общего количества). Рассматривать типовые управленческие бизнес-процессы вряд ли целесообразно в силу различия правовых систем и нормативно-законодательной базы в России и за рубежом. Мало того, даже внутри России стандартизация управленческих бизнес-процессов вряд ли возможна из-за существенного различия нематериальных активов в отечественных организациях, их стратегической и тактической нестабильности, включая лиц на предприятии заказчика, принимающих решение о реинжиниринге.Впрочем, здесь необходимо учитывать, что имеются в виду организации и структуры высокотехнологичных направлений, т. е. я говорю об основах оборонного комплекса, об их положении сегодня. Я не рассматриваю такие отрасли, как, например, торговля, магазины, что-то ещё...
Поэтому, когда речь идёт в большей степени о производственных процессах, вариант подхода "клиента под проект" возможен только для некоторых типовых бизнес-процессов. Во всех остальных случаях должен работать вариант "проект под клиента". Заметим, что это подтверждают сегодняшние тенденции мирового рынка информационных технологий. "Клиенты готовы платить за развёртывание решений и поддержку - за то, что приносит успех их бизнесу. Не думаю, что сегодня кто-то готов платить за программный код как таковой", - говорит Стив Миллз, старший вице-президент IBM (группа программного обеспечения). Примерно о том же говорил Михаэль Ирингер, директор по маркетингу по Центральной и Восточной Европе корпорации InterSystems, на международном симпозиуме, проходившем в Москве в июле 2005 года. Он наглядно продемонстрировал смещение акцентов в процессе развития рынка информационных технологий за последние 10 лет:
Иначе говоря, для исполнителя задача сегодня должна стоять как "проект под клиента". Заказчик в этом случае получает требуемую ему бизнес-модель, которая, как он считает, должна обеспечить ему конкурентное преимущество, и не ломает голову над выбором конкретных программных продуктов.
Андрей Монахов (ИД "Бухгалтерия и банки", заместитель генерального директора). Получается так, что в государственном секторе всё это звучит как жёсткие требования и подход "проект под клиента"...
Реплика из зала. Ничего это не получается...
Сергей Проскурин (фирма "ЛокИС", генеральный директор). Мы не услышали собственно про государственный сектор. Мы услышали некие высказывания, которые некий западный менеджер возвестил на каком-то семинаре. Мы участвуем в наших, отечественных выставках с 1990 года, и то, что вы сказали, к нашей стране не имеет никакого отношения.
Николай Дерябин. Я говорил о мировых тенденциях.
Сергей Проскурин. Бог с ними, с мировыми тенденциями. Если мы будем говорить о мировых тенденциях - это одно дело. Если бы вы сказали о каком-то предприятии, на котором разработана конкретная бизнес-модель, я бы тогда поинтересовался этим предприятием, и очень хотелось бы увидеть эту бизнес-модель. Но такой модели нет ни на одном предприятии, а уж тем более в государственном секторе, где, как известно, эффективность гораздо ниже, чем в той же торговле. Вот в торговле-то бизнес-модели как раз гораздо лучше разработаны и реально действуют, в отличие от любого из наших предприятий. Здесь же в основном разработчики собрались, поэтому предлагается выражаться конкретнее.
Владимир Пичугин (компания "Интеллект-Сервис", директор). Я здесь выскажу третью точку зрения: так явно ни то, ни другое не присутствует. Дело в том, что у нас очень успешно внедряется на производственных предприятиях, в том числе государственных, система "ИС-Про", в которую включены, в общем-то, стандартные бизнес-процессы для производственных предприятий. Конечно, есть настройки, но я не соглашусь с тем, что система настраивается только под клиента. Клиент тоже нередко перестраивает свои процессы под систему.
Мы более пятнадцати лет разрабатывали эти системы. Всё-таки бизнес, опыт бизнеса и опыт тех бизнес-процессов, которые на предприятиях внедряли, весь собран и отражён в хороших системах, в том числе и в наших. И тогда на том же производственном предприятии их часто рассматривают не только как автоматизированные системы, созданные по принципу "сделайте мне то и внедрите так, как я хочу". Они уже становятся учебником по бизнесу. Да, и такое тоже бывает: "а вот покажите, как другие работают". А как другие работают - это уже заложено, "прошито" в программах. И очень часто бывает, что, посмотрев, как это можно делать, меняют свои бизнес-процессы, причём никто не заставляет их это делать насильно, типа "или так, или никак". Сами меняют, потому что признают: да, это более эффективно. Поэтому тут я с Сергеем Проскуриным согласен, что вот таких прописанных, чётких, стандартных бизнес-процессов - их, наверное, нет нигде. Хотя предприятия принадлежат одной отрасли, более или менее одинаковы, но работают они по-разному. Да, основные бизнес-процессы отрасли более или менее похожи, но всё равно приходится в деталях многое подстраивать. Естественно, надо подстраивать под конкретное предприятие. Если, к примеру, возьмём 20 хлебозаводов, то на 80 % у них всё может быть и одинаково, а остальное приходится от предприятия к предприятию дорабатывать, подстраивать.Но это не означает, что полностью всю систему надо переделывать. Есть базис какой-то, и есть какие-то средства, процессы, которые надо адаптировать. Но в чём я не соглашусь, так это в том, что существуют российские бизнес-процессы и западные. Вот мы работаем сейчас и с российскими системами, и с западными. Такие же бизнес-процессы, как и у них. Вот мы занимаемся автоматизацией торговли автомобилями. Продают автомобили автодилеры; что тут продаём, что там... Действуют, как правило, по тем же стандартам, задаваемым производителями. В чём разница? В том, что бухгалтерия у нас по-другому считается, вот и всё. А реально-то бизнес-процессы покупки, продаж - они, в общем-то, те же самые.
Андрей Орлов (компания "Росагролизинг", начальник ИТ-отдела). Кстати, о специфике русских процессов, в качестве реплики единственный вопрос: ваша система, которая торгует автомобилями, в состоянии продать автомобиль до того, как он оприходован, т. е. поступил?
Владимир Пичугин. Это на самом деле не специфика. Имеется так называемый аванс. Это мировые схемы, когда что-то авансируется...
Андрей Орлов. Дело не в том, что авансируется, а в том, что автомобиль уже приехал и его отдали клиенту. Вот надо эту операцию провести в системе, хотя товар ещё не встал на учёт - его не оприходовали.
Владимир Пичугин. У официальных дилеров западных поставщиков такого не бывает. Там есть стандартные бизнес-процессы, и они предусмотрены в тех же западных системах.
Елена Ашарина (консалтинговая группа "РОЭЛ Консалтинг", директор администрирования проектов). Мне очень не нравится, когда говорят о стандартных бизнес-процессах, потому что бизнес-процессы всегда определяются системой управления. А система управления - она... нестандартна. Не бывает типовых систем управления. Система управления определяется прежде всего собственниками. И там - у собственника - всегда существует широкий диапазон для её вариантов. Если мы, например, пойдём на уровень производственной площадки, то там можем выделить какие-то типовые операции, действительно связанные с преобразованием, изготовлением чего-то. Кстати, можно сказать, что торговля менее замысловата в своих процедурах. Типологизация есть. Но когда мы переходим на уровень управления, то там бизнес-процессы все подчинены именно системе.
Реплика из зала. А что такое бизнес-процессы на уровне управления? Пример, пожалуйста, приведите.
Елена Ашарина. Если я собственник, то я ввожу свою систему управления и говорю: вот это подразделение отвечает за это, а вот то отвечает за то, а вот здесь они скоординированы...
Реплика из зала. А какое отношение это имеет к системе?
Елена Ашарина. Как какое? А документооборот, а регламент? Регламентация, матрица ответственности. Что можно делать и что нельзя; какие операции разрешены и какие запрещены...
Реплика из зала. Это несколько другой вопрос. Это скорее уже о разграничении прав доступа.
Николай Комлев. Так, давайте всё же по очереди.
Игорь Якобсон (компания "Компас", СПб, главный эксперт). У меня такое впечатление, что никто здесь не спорит абсолютно, хотя все изображают горячий спор. То есть уже было сказано - Владимир Пичугин прекрасно сказал: примерно 80 % одинаково, тут зависит от отрасли. Вот Сергей Проскурин сказал, что в торговле более стандартизованно, чем, скажем, сегодня в промышленности - согласен. Теперь о том, с чем это связано. Что такое бизнес-процесс? Это совокупность операций, взаимосвязанных технологий, процессов, работ. Так вот 80 % из них, в какой-то отрасли 70, где-то 60 - вполне укладываются в стандартизованные: никто не спорит - можно брать готовые, можно обмениваться опытом, набирать, скорее заимствовать опыт и т. д. Но если мы хотим бороться с конкурентами, то у нас должна быть своя изюминка, за счёт чего мы и выигрываем у них.
Реплика из зала. У кого? С кем мы конкурируем?
Игорь Якобсон. У конкурентов торговых предприятий - торговые конкуренты. У автодилеров - автодилеры. В конце концов, у производственных предприятий - производственные. Поэтому где-то 10, где-то 20 % всегда будут индивидуальными в бизнес-процессах. По-разному организованные процедуры, по-разному структуризованные системы управления, разный документооборот, разные маршруты... Кстати, будучи на другом "круглом столе", я с изумлением понял, что когда о бизнес-процессах говорят автоматизаторы документооборота, то они почему-то приравнивают их к тому, что я называю маршрутом Workflow. Для них это синонимы: маршрут Workflow - модель какого-то бизнес-процесса. Но даже если говорить о маршрутах, то, может быть, и тут можно 80 % сделать стандартными, 20 % должны быть индивидуальными, и система должна быть настраиваемая.
Николай Дерябин. Маленькую ремарку можно о стандартизации? Когда мы здесь давали определение понятию процесса, это была взята формулировка из наших российских стандартов, только я добавил материальные и нематериальные активы - заменив материальные и информационные потоки, - и всё. Это стандартная формулировка.
Андрей Орлов. Согласен с Игорем Якобсоном: в зависимости от предметной области 60-80 % бизнес-процессов можно стандартизировать. Но нам, клиентам, очень часто приходится сталкиваться с убеждённостью разработчиков, что именно в их системе все типовые бизнес-процессы предусмотрены и могут быть реализованы, а всё, чего система сделать не сможет, - это "неправильные" бизнес-процессы, которые нужно переделать. Мягко говоря, это не всегда так. Если в качестве примера взять розничную торговлю, то вряд ли какой-нибудь сторонний автоматизатор сможет убедить хозяина успешного бизнеса изменить систему скидок и бонусов покупателям, потому что они не являются типовыми. Так что уж если компании "К+С", торгующей обувью захотелось дарить покупателям арбузы, то такой бизнес-процесс должен информационной системой учитываться безусловно и безотносительно к его стандартности.
Кроме того, существует множество сфер деятельности, в которых предприятий не слишком много. Для таких предприятий отдельных типовых версий информационных систем никто не разрабатывал. Поэтому и бизнес-процессы, являющиеся стандартными для них, ни в одной из систем не реализованы. А в организации, где я сейчас работаю, бизнес-процессы утверждены советом директоров, в который входят министр и три заместителя других министров. И, как вы понимаете, менять эти бизнес-процессы по рекомендации автоматизаторов тоже никто не будет.
В таких случаях тиражируемую систему приходится дорабатывать. Параметрическими настройками обойтись не удаётся.
Владимир Борисов (компания ISBP, Череповец). Я бы перевёл стандартизацию бизнес-процессов немножко в другую плоскость. Тут называли 80 %, 20 %, но вот я бы сказал, что более крупные процессы, например процесс учёта материала, его перемещения со склада в производство и прочее, в принципе стандартны практически на все 100 %. Различия начинаются ниже, когда идёт декомпозиция процесса. И вот здесь уже могут возникать всевозможные отклонения от этих стандартов.
Андрей Орлов. Если вы рассматриваете один бизнес-процесс, если вы считаете, что он эквивалентный, то как у вас декомпозиция получается разная?
Владимир Борисов. Просто есть разные структуры предприятия, разные функции, и это частные бизнес-процессы, которые входят в состав более общего бизнес-процесса. Поэтому они и получаются разными. А вот если взять глубже, ближе подойти к элементарному действию, то там и начинаются основные различия. Здесь важно дать системе такую возможность, чтобы сам пользователь составлял эти бизнес-процессы и подстраивал её таким образом. То есть напиши, что ты хочешь сделать, подключи исполнителей и документы и получи информационную систему.
Реплика из зала. А где вы таких пользователей возьмёте? У вас такие есть?
Владимир Борисов. Такие пользователи сейчас есть у каждого. Может быть, мне везёт и именно я встречаю таких пользователей - они начинают прописывать бизнес-процессы. Начинают для этого применять различные стандарты средства: IDF0, ARIS, UML.
Николай Комлев. Простите, можно привести пример таких пользователей: они большие, маленькие?
Владимир Борисов. Вот у нас, в Череповце, много предприятий, банков в том числе, которые используют стандарт IDF0 для описания процессов. Кому нужно получить сертификат ISO-9000, то это документированная процедура. Стандарт ISO-9000 никаким образом не регламентирован. Процессы должны быть прописаны. Это можно сделать в стандарте IDF0, в ARIS их можно прописать в виде таблиц, просто как текстовые...
Реплика из зала. Они, как правило, не имеют никакого отношения к реальной действительности.
Владимир Борисов. Вот это верно. Они действительно редко используются в жизни.
Там, где мы прописываем бизнес-процессы, они должны быть живыми. Они должны выдавать задания тем исполнителям, которые задействованы в процессе, и работать с теми документами, которые подключены к этим бизнес-процессам. Вот такая система, с одной стороны, при постановке бизнес-процесса будет стандартная; и чем дальше эти процессы будут декомпозироваться, тем ближе будет предприятие бизнес-процессу клиента. Иначе говоря, мы не должны строить систему под клиента, чтобы учесть его интересы, и не должны навязывать систему, чтобы клиент под неё подстраивался. Нужно дать такой инструмент, с помощью которого сам пользователь строит свои бизнес-процессы и информационную систему.
Алексей Нестеров (фирма "1С", директор по производственным решениям). Хотелось бы вначале остановиться на приведённых ранее высказываниях зарубежных коллег. Во-первых, их можно по-разному интерпретировать. То, что, например, в восьмидесятых годах или в девяностых было время решений как программ, а сейчас время именно решений - это необязательно может касаться индивидуальных проектов, как это здесь интерпретировали. Это может быть по-разному переведено, и разный смысл закладывается в них, по-разному понимается. Это могут быть те же отраслевые, специализированные, более адаптированные решения. Как, например, коллеги про автотранспорт говорили.
Теперь что касается того, насколько вообще "типовое" или "нетиповое" решение может быть создано для конкретного предприятия. Во-первых, конечно, полностью согласен с тем, что в каждой отрасли есть какие-то свои процессы, которые можно стандартизировать, описать, и это решение будет намного больше подходить большей части этих предприятий. Мы (фирма "1С", её партнёры) как раз разрабатываем сейчас много отраслевых решений, и, допустим, через два-три месяца должно выйти какое-то отраслевое решение. Многие партнёры, которые сегодня ведут разработку, говорят следующее: "У нас сейчас клиенты не покупают текущую версию; они ждут, когда эта разработка (или другая) действительно будет сертифицирована фирмой "1С" как отраслевое решение. Мы, как клиенты, тогда будем уверены, что оно станет типовым для отрасли, что мы уже сможем (будем) использовать те стандартные бизнес-процессы, которые в нём уже заложены, и что таким образом мы минимизируем затраты на его внедрение".
И что ещё важно отметить: есть бизнес-процессы, которые действительно относятся к каким-то учётным задачам, а есть относящиеся к управленческим, которые обеспечат конкурентоспособность предприятия. Общаясь в последнее время с некоторыми крупными клиентами, мы нередко слышим: "Да, у нас там всё индивидуально, всё особенное, у нас там есть ISO-9000...", но большинство сразу говорит, что те бизнес-процессы, которые там прописаны, можно было не рассматривать - это нужно было для сертификации, а не для работы. Это же подтверждает и наш опыт... Многие клиенты с интересом, детально рассматривают программный продукт - либо отраслевой, либо типовой - и готовы всегда перестраивать свои бизнес-процессы в тех случаях, когда это позволит потом сэкономить деньги на сопровождении продукта. И, конечно же, готовы вкладываться в разработку каких-то модулей, в адаптацию тех, которые создают их конкурентное преимущество или будут способствовать укреплению уже имеющегося.
Сергей Проскурин. Некоторые знают мою нелюбовь к словосочетанию "бизнес-процесс", потому что оно абсолютно ничего не раскрывает и только затуманивает картину. Об этом я на других "круглых столах" уже говорил, моя позиция в целом известна, и она "в меньшинстве". Но тем не менее. Право на готовый продукт в нашей области имеет место быть. То есть это право подтверждено и нашим опытом, и не только нашим.
Вот мы слышим о каких-то там 80 % стандартных процессов, 70, 90, а кто их и как считал? И моя-то благая цель участия в этом мероприятии - ещё раз подчеркнуть один существенный момент: есть важная проблема, которая достаточно широка, чтобы посвятить ей большие силы, оформить это каким-то образом или начать вести исследования в области автоматизации.
А что такое автоматизация? На прошлом "круглом столе", на SofTool-2004, я как раз и говорил: суть всех наших автоматизированных изделий - это овеществить в программах опыт управления предприятием. И в этом как раз и состоит тенденция. Но у нас нет сегодня отрасли знания, которая исследовала бы автоматизацию... или нужные её области. На самом деле, где получить данные исследований, которые бы установили, что вот на этом предприятии 70 % бизнес-процессов являются общеупотребительными в этой отрасли? Никто этого не скажет - таких исследований не проводится. Но все рассуждают о бизнес-процессах и о степени их соответствия стандартным или нестандартным.
Реплика из зала. А экспертного мнения не может быть?
Сергей Проскурин. Не может быть, потому что здесь должно быть мнение конкретное: если приведём формулировку бизнес-процесса, с которой никто не спорит, то это совершенно конкретное мнение. Как только начинается разговор о бизнес-процессах, то какой пример почти всегда приводится? "А вот, вы выписываете накладную...". И, кстати, правильный пример: это один из бизнес-процессов. Если уж рассуждать, то в первую очередь к стандартным бизнес-процессам следует отнести те, которые нормированы законодательством. Вы обязаны выписать накладную с такими-то полями, параметрами, с такими-то подписями, с такими-то реквизитами. Понимаете, это нормированное законодательство! Вот пример стандартного бизнес-процесса. Так же и все балансовые отчёты, все бухгалтерские отчётности, все бухгалтерские операции - это стандартизованные бизнес-процессы, и спорить здесь совершенно не о чем. А дальше то, о чём говорила Елена Васильевна, ей это ближе, она занимается проблемами управления предприятиями - есть ещё бизнес-процессы внутренние.
Вот Игорь Якобсон говорил о бизнес-процессе с точки зрения ведения документооборота. Каждый сам организует на своём предприятии внутренний документооборот, который также является бизнес-процессом. Который влияет на эффективность этого предприятия. Который может быть автоматизирован. И потому-то тема эта на самом деле очень интересная, как мне кажется. То направление, которое я представляю, - это "клиента под проект". Мы пошли по конкретному пути: мы разрабатываем, как можем, максимально полное решение для определённой отрасли, клиент его анализирует, и, если оно ему подходит, он его выбирает и у себя использует. Тем самым у него, безусловно, минимизируются все затраты по внедрению, надёжный продукт получает и т. д. Ну, естественно, это не охватывает всех клиентов. Если приходит ко мне клиент и говорит "а я вот хочу это, но только как у меня", то я отвечаю: "Извини, дорогой, это не ко мне. Для этого, скажем, есть "Интеллект-Сервис", "ТБ.Корпорация" или много других компаний, которые делают проект под конкретного клиента". И мне казалось, что именно эта альтернатива высвечена и важна в этой теме "круглого стола".
Николай Комлев. А можно уточнить: прозвучала идея, что формализуемый бизнес-процесс - это тот, который в основном регламентирован государством?
Сергей Проскурин. Нет, это то, что, безусловно, может быть стандартизировано. И вот в развитие этого факта: ведь есть МСФО и прочие общие стандарты: если бы государство больше занималось этими вопросами (унификации, стандартизации, регламентов), в какой-то мере было бы легче.
Считаю, что в любом случае это пошло бы на пользу всем нашим предприятиям и нам в том числе - легче будет работать. Если хотя бы та отрасль отчётности предприятия, которую обусловливает государство, была стандартизована - ну тогда всё: у нас доблестная компания "1С" со всеми своими франчайзи родила бы единое стандартное решение, и ни о чём не надо было бы думать. Вот как только выходим на уровень получения отчётности - нажимаем одну кнопочку под названием "1С", такая жирная красная - точнее жёлтая - кнопка на клавиатуре или экране.
Андрей Орлов. Эта госчасть у нас стандартизована очень хорошо, только она каждый год или даже чаще стандартизуется по-новому...
Реплика из зала. Спасибо государству...
Владимир Борисов. Вот здесь в определении бизнес-процесса ничего в принципе не сказано о ресурсах. Как тут сказали, стандартный бизнес-процесс, скажем, - это выписка накладной. Его может сделать и один человек. Его же может делать целая группа, и всё будет иначе: один вписывает или делает одно, другой - второе, третий - третье...
Сергей Проскурин. Это непринципиально. Моя идея в том, что нам, в частности, я думаю, именно разработчикам и всем заинтересованным пользователям, надо как-то побудить вести исследования вот тех самых бизнес-процессов. Это изучение опыта управления предприятием, его формализация, нормализация. Понимаете? Чтобы получать количественные показатели.
Евгений Валкин (фирма "Фолио", директор). Я хочу два слова сказать: озвучивая и споря по темам "клиент для проекта" или "проект для клиента", мы не согласовали цели. Кому от этого должно стать лучше: разработчикам или клиентам?
Реплика из зала. Тому, кто деньги платит.
Евгений Валкин. Кто для кого тогда? Потому что, понимаете, если смотреть на проблему со стороны разработчика, то удобнее во многих случаях использовать готовые решения и соответственно загонять клиента под любой проект. А глядя со стороны клиента - делаем ли мы ему лучше? Кому же мы хотим сделать лучше в данном случае?
Николай Комлев. Это неочевидно. Вот вы говорите: "Разработчику удобнее, чтобы клиент перестраивался". Нет. Тоже неочевидно. Если у тебя будет условно только одно решение и негибкая система, ты проиграешь в конкуренции с другими.
Евгений Валкин. Тоже неочевидно. Вообще, по этому поводу спорить можно долго... Я наблюдал, если можно так выразиться, по крайней мере три типа клиентов. Первый - это когда сами пользователи пытаются совершенно неграмотно поставить задачу. В результате что-то непременно встанет. Или получается такой безумный бизнес-процесс, который со скрипом работает и в любую минуту может рухнуть. Второй вариант - когда клиенты соглашаются с общей тиражной коробочной технологией, и всё идёт нормально. А в последнее время (особенно такое происходит среди наших крупных клиентов) нам говорят: "Вы покажите вообще, как у вас налажен готовый бизнес-процесс, как, на ваш взгляд, лучше всего вести по такому типу бизнес-процесс". Тут тоже в каком-то смысле используется готовый процесс. Но всё-таки не совсем понятно, какова цель: мы хотим оптимизировать проект или мы хотим оптимизировать свою деятельность?
Николай Комлев. Вот прямо с этого момента мы плавно переходим на вопросы второго раздела. Получается, что для успеха необходимо согласование интересов сторон, взаимопроникновение в технологии, поэтому какая-то взаимная настройка неизбежна, так? Давайте поговорим на вторую тему.
Раздел 2.
Если "взаимонастройка" неизбежна, то кто и как принимает решение о реинжиниринге бизнес-процессов на предприятии заказчика? Как происходит распределение ответственности между исполнителем и заказчиком при выборе и осуществлении того или иного подхода в автоматизации бизнеса? Насколько реинжиниринг экономически оправдан для заказчика и для внедренца? Существует ли реальная ответственность за убытки, которые может понести предприятие? Имеется ли в вашей системе блок моделирования бизнес-процессов и насколько он необходим? Кому он больше нужен - исполнителю, заказчику, консалтинговой фирме?
Николай Дерябин. Совершенно правильно заметил Евгений (Валкин): не праздный вопрос, в чьих интересах ведётся проект. И вообще, когда звучит мнение только одной стороны, скажем, высказываются лишь поставщики, - это не совсем "круглый стол" получается, поэтому попытаюсь разбавить обсуждение и другой позицией. Как представитель стороны заказчика, вот что я имею в виду. Когда говорят, что вот, мол, есть такой замечательный программный продукт - берите его, лучше всё равно не найдёте, или даже - другого вообще нет, то это говорит или о нежелании, или о неспособности поставщика полностью удовлетворить запросы и потребности заказчика. Заказчик, на мой взгляд, должен иметь описание рабочих технологий, или технологии работы своих систем, - чтобы было с чем работать. А уж как построить конкретный бизнес-процесс, исполнитель и заказчик могут решать и совместно. Хотя у нас на большинстве предприятий авиационной отрасли, в ОПК всё приходится решать самим заказчикам. К примеру, если вы слышали, авиационное производственное объединение в Комсомольске-на-Амуре, известная фирма, поставляет "Су-27", в Иркутске фирма "Иркут" - "Миг-29", и там вопросы автоматизации, в общем-то, достаточно глубоко проработаны. Однако всё это лежит на плечах самого заказчика.
Николай Комлев. Хотел бы уточнить: вот там в девяностые годы разве не меняли бизнес-процессы?
Николай Дерябин. В девяностые меняли.
Николай Комлев. Меняли, ориентируясь на что?
Николай Дерябин. На жизнь, только на жизнь. Бизнес-процессы и структура управления на предприятих ОПК относятся к уровню ЕRP-систем. Кстати, насчёт стандартизации: вот здесь правильно сказали, что в управлении что-то стандартизовать и даже типизировать почти невозможно. Поэтому даже за рубежом ЕRP-системы не имеют стандартов, и вы это прекрасно знаете. Иначе говоря, на Западе понимают, что это нельзя стандартизировать даже для их условий, когда там жёсткое и внятное законодательство. А у нас тем не менее пытаются это делать. Поэтому, когда у нас на предприятиях ставят западную систему, скажем Baan, то она используется на 10-15 %. Всё остальное - это выброшенные деньги.
Алексей Корявко (фирма "ЭЙС", директор). В своё время - в те самые девяностые годы - я "служил" в одной организации, называемой НИИ экономики МАП (Министерства авиационной промышленности. - Примеч. ред.). Как раз там и разрабатывали некоторые подходы, стандарты и пр., т. е. занимались тем, чтобы все эти предприятия отрасли отличным образом направить и отрегулировать. Туда собрали самых умных специалистов, к ним добавили ещё некоторое количество учёных, чтобы те вместе с этими умными как-то попытались определить и скоординировать основные направления текущего развития и на перспективу, разработать соответствующие подходы, технологии, модели... Были рассчитаны модели аж до 2035 года. Но потом случилась "перестройка", и эти предприятия оказались никому не нужными. Одним из первых "изничтожился" как раз НИИ экономики. На его площадях разместился банк "Менатеп", потому что новой стране стали нужнее банки. На этом всё и кончилось. Сейчас мы пожинаем результаты тех "революционных" и "дальновидных" шагов и всего, что затем произошло. Сегодня у нас в авиации хорошо если ещё остались две-три фирмы, два-три КБ, которые демонстрируют в качестве последних достижений наработки 12-15-летней давности. Хорошо, что у нас страна большая, что у нас есть Комсомольск-на-Амуре, Иркутск, куда, видимо, ещё не докатилась волна "перестройки": они в практически полностью разрушенной инфраструктуре ещё сами пытаются что-то делать, как-то выжить. Всё остальное практически уничтожено. Где микояновские фирмы, где яковлевские фирмы? Что они теперь делают? Кто ими управляет? Была нормальная, а по сегодняшним меркам - так просто замечательная структура управления: сам МАП, НИИ экономики МАП и пр.
Там работали специалисты, какие-то специальные отделы, считали, пытались стандартизировать и оптимизировать процессы, как мы это теперь пытаемся делать каждый для себя и кто во что горазд. Но государство решило, что это всё не годится и никому не нужно. И поэтому оно, как обычно, разрушило старую систему управления, не построив новой. А вот моё личное мнение по поводу "проекта - не проекта": если сейчас на элементарное торговое предприятие приехать и сказать: "Знаете, мы вам поставим вот такую чудесную, прямо-таки волшебную систему некоего западного разработчика. Только вот вы свои бизнес-процессы измените, так как они у вас уже устарели. И пойдут у вас дела просто шоколадно". Я думаю, что после этого всё элементарно рухнет.
Реплика из зала. Стопроцентно! Вам, слава богу, в торговле не дадут этого сделать... в отличие от авиационной промышленности.
Алексей Корявко. С нашей точки зрения, или исходя из нашего опыта, если предприятие действует и хочет развиваться дальше, то оно, как правило, держится за того разработчика, который поставил ему нечто подходящее, к тому же совпадающее с перспективой его развития. И подобное сотрудничество обычно продолжается многие годы, во всяком случае достаточно долго. Иными словами, они вместе непрерывно совершенствуются, учатся, растут и развиваются. Нельзя вдруг притащить им что-то или сделать в течение недели нечто такое, чудесное. Всё это происходит непрерывно и постепенно: если предприятие работает с тобой (как с разработчиком, поставщиком), то тебе будет идти непрерывный заказ. То есть в большинстве случаев нет такого: сделал, оставил - и всё. Если система автоматизации, что называется, тормозит, "не догоняет", разработчик остановился, значит, заказчик ищет альтернативу, вынужден перейти куда-то, на другие бизнес-процессы, так как твои не нравятся. В противном случае заказчик завтра "рухнет". Что и происходит даже с крупными компаниями. Сколько таких наша фирма пережила? Их просто не стало. И не потому, что мы им предлагали плохие бизнес-процессы, а потому что ими так управляли. Мы же выполняем вспомогательную функцию.
Сергей Проскурин. Вот именно, наконец-то у вас это прозвучало: именно "вспомогательную", а то можно подумать, что чуть ли не вы сами управляли этими предприятиями.
Алексей Корявко. Нет, мы только помощники, реализующие работы по автоматизации. Кто-то бумагу поставляет, кто-то ещё что-то, а мы им поставляем информационные технологии.
Сергей Проскурин. Действительно, мы можем только помочь реализовать те потенции, которые есть у предприятия, и поэтому переоценивать свой вклад я лично не намерен. Если на предприятие свалились, бог весть откуда, бешеные средства и оно не знает, куда их потратить, то оно может покупать Baan, может SAP или ещё что "покруче", но толку от этого мало. Если у них есть голова на плечах, то они будут привлекать ИТ-специалистов и реализовывать информационные технологии вместе с вами, со мной и т. д., управлять грамотно, современно. И будут развиваться.
Вы, Алексей, совершенно правы, говоря о постепенности и непрерывности развития, это подтверждает и наш опыт. Мы имеем ряд клиентов, которые работают с нашей фирмой уже более десяти лет. К примеру, "Крокус" уже 13 лет работает. И не собирается менять поставщика ПО. Не потому, что мы ими управляем или даём им какие-то суперсовременные бизнес-процессы. Ничего подобного! Просто мы можем реализовать все те идеи, которые пришли им в голову для успешного управления. И система обязательно должна развиваться вместе с предприятием. Остановился - "умер". Поэтому думать, что стоит только купить какую-нибудь совершенную западную систему и дальше ничего не нужно будет делать, - это заблуждение.
Андрей Монахов. Скажите, вы подсчитывали в процентном соотношении, сколько ваших фирм, с которыми вы сотрудничали, рухнуло? Кто удачно, а кто неудачно работал?
Алексей Корявко. Это, во-первых, скорее всего новички на рынке. А во-вторых, это все, которые работали с "Гепардом", - они и рухнули (шучу). Но это вопрос совсем из другой плоскости. Это умение вести бизнес и роль ИТ, разные понятия и модели.
Сергей Проскурин. Кстати, я могу привести такую статистику. Наша система "ЛокОФФИС" начала продаваться с 1992 года. Значит, с этого года один "Крокус" пока что уцелел, хотя было продано тогда 18 систем. В 1993-м тоже единицы уцелели. Вот в 1995-м живут уже побольше, кое-что осталось...
Реплика из зала. Так ведь до того кризис случился...
Сергей Проскурин. Нет, это просто жизнь. Тогда было самое начало. Извините, но в 1991 году, когда мы показывали сетевую систему на 17 мест на единой базе на выставке SofTool-1991, вообще практически никто не понимал, что мы показываем. Сетевых-то решений тогда, кроме нашего, вообще представлено не было, кстати, западных тоже. Пожалуй, единственная система, которая присутствовала тогда на рынке и мало-мальски подтягивалась к нашему уровню, была сделана на базе "Прогресса".
Я это к тому говорю, что западные пришли позже, но они идут и сейчас уже просто рвутся на наш российский рынок. И конечно возьмут свою долю денег с этого рынка. Но выживать предприятиям всё-таки придётся - я лично в это верю - именно с нашими системами. Если с западными, то очень сильно адаптированными, переработанными нашими же специалистами. Возьмём известный пример со "Скалой", которую уже переписали десять раз.
Андрей Монахов. Сергей, не расстраивайтесь, чем больше у фирмы клиентов, тем больше соответственно и тех, кто "рухнул" или "рухнет"...
Николай Дерябин. А можно вопрос ко всем поставщикам продуктов? Вот вы статистику вели определённую. Скажите, пожалуйста, как часто вам приходилось работать именно с первыми лицами фирм, предприятий при внедрении продукта? Или вообще никогда не приходилось?
Сергей Проскурин. Отвечу. Дело в том, что прежде, чем выпустить свою готовую систему "ЛокОФФИС", мы сделали, включая и 1993 год, пять заказных систем. И успешно их внедрили. Среди заказчиков были торгово-закупочная база московского гарнизона, оптово-розничное предприятие, крупное для тех времён совместное предприятие "Рефлекс", трест "Электроцентрмонтаж". Причём первая система, которую мы показывали на выставке в 1991 году, была сделана как раз для треста "Электроцентрмонтаж" Минэнерго СССР, у которого было десять монтажных управлений по всей стране, ещё был трест и один заводик. Естественно, что эти проекты велись при взаимодействии с первыми лицами. Замечу, что система "ЛокОФФИС" в 1992, 1993 годах была дороже всех отечественных систем на рынке и покупалась только с участием первых лиц.
Но как только она стала продуктом тиражным, доступным, скажем так - общеупотребительным, известным, то мы, конечно, отошли от подобных контактов, потому что вообще отошли от контактов с заказчиками. Мы просто отказались от проведения проектных работ, и тут я сажусь на своего "конька": имеется в виду реализация такого готового продукта, который продаётся на рынке и обходится без его внедрения со стороны разработчика.
Справка: с 1992 года наша фирма ни разу не внедряла у заказчиков свой продукт. При таком подходе контакты с первыми лицами не нужны. Это как телевизоры. Или же, к примеру, сегодня никому в голову не придёт покупать "мерседес" и требовать контакта с главой корпорации "Даймлер-Крайслер-Бенц", или как её там... Но когда речь идёт о проекте, тем более о серьёзном, - это нужно обязательно.
Николай Комлев. Итак, это один полюс, да? А другой полюс - альтернатива, когда внедряют, когда есть консультанты, когда есть реинжиниринг. Вот с этим опытом кто-нибудь сталкивался? Поделитесь.
Реплика из зала. Да, вот, например, Андрей Георгиевич Орлов...
Николай Комлев. А из разработчиков?
Владимир Пичугин. То, что сказал Сергей Проскурин, - это, мне кажется, больше было характерно для тех массовых бухгалтерских программ второй половины 1990-х годов, когда программы покупались в основном главным бухгалтером и внедрялись в бухгалтерии. Если раньше был подход "пусть бухгалтер сам выберет, с какой ему системой удобнее работать", то сейчас тенденция пошла иная: нужны уже управленческие решения, нужна комплексная система управления предприятием, бизнесом. Сейчас решения всё больше и больше принимаются первыми лицами. Внедряются крупные системы, которые помогают управлять многими подразделениями, деятельностью всей компании. И, естественно, принимают решения уже на гораздо более высоком уровне - чем дальше, тем больше: это решается на уровне финансового директора, генерального директора, президента фирмы и т. д.
Николай Дерябин. Генеральный, скажем, подписывает. А вот принимает ли он решения?
Владимир Пичугин. Принимает. Именно они и принимают решения.
Реплика из зала. А готовит кто?
Владимир Пичугин. Готовят - и ИТ-службы, и финансовые службы, и коммерческий директор... и все остальные. А окончательное решение принимают первые лица. В наше время имеет место уже другая тенденция. Сейчас бизнес на самом деле укрупняется: чем больше бизнес, тем крупнее проекты и соответственно выше уровень принятия решений.
Сергей Проскурин. А кто подбрасывает на стол шарик решения, который большой начальник схватит?
Владимир Пичугин. Конечно, с подачи ИТ-отдела. Естественно, готовит ИТ-директор в первую очередь. Причём то, что подготовил ИТ-директор, не всегда принимается. Но решения принимаются - чем дальше, тем выше. Чем сложнее система, чем крупнее она, чем дороже для предприятия стоит, тем более высокий пост должен будет принимать это решение.
Николай Дерябин. Я несколько другое имел в виду. Принимает сознательно или бессознательно? На минуту пришёл в сознание - подписал. Это не совсем то.
Владимир Пичугин. Разумеется, сознательно. Сейчас это уже таких денег стоит...
Реплика из зала. Многие ли директора могут похвастаться, что у них есть успешный опыт внедрения крупных автоматизированных систем и работы в структуре ИТ?
Николай Дерябин. Вот почему эта проблема и сама тема очень интересны для обучения, образования: сначала обучить надо, чтобы директора, ответственные лица, менеджеры разных уровней могли грамотно с вами работать.
Сергей Проскурин. Вот только директоров уже бессмысленно обучать. Этим надо было заниматься, когда они были детьми. Они же не будут учиться - просто дипломы купят.
Николай Васильевич (обращается к Комлеву), я хотел бы, чтобы мы послушали Елену Васильевну Ашарину в качестве специалиста по консалтингу. Дело в том, что она является директором департамента ИТ-проектов и прочих решений в компании "РОЭЛ Консалтинг". Она работает, по-моему, с десятью заводами. В части именно управления, постановки, набора команды, которая будет реализовывать проект. Общается на самом высоком уровне именно с директорами этих предприятий. И мне кажется, что её взгляд будет многим интересен. Николай Иванович Дерябин очень правильно сформулировал и поднял вопрос: сознательно или бессознательно принимается решение руководством?
Николай Комлев. Или с подачи консультанта. Попробуем здесь плавно влиться в русло третьего раздела нашей темы и поговорить о роли и месте консалтинговой компании.
Раздел 3.
Посредник, партнёр или генподрядчик?
Существуют ли нейтральные "реинженеры" (не ангажированные двумя-тремя известными компаниями - производителями прикладного ПО)?
Как изменились консультанты за последние 5-7 лет?
В вашей практике кто чаще берёт на себя роль генподрядчика - консалтинговая компания или разработчик (внедренец) системы?
Чьим "заложником" становится клиент - консалтинговой компании, разработчика, внедренца?
Елена Ашарина. Наверное, все отдают себе отчёт в том, что ИТ-решение для производственной компании формируется и создаётся гораздо дольше. В отличие от предприятий сферы, торговли, предоставления услуг отыскать полновесные типовые отраслевые производственные решения весьма сложно. Здесь каждое предприятие, каждое решение отчасти уникально. И поэтому производственные проекты нередко идут с трудом и долго, а опыт отрицательных внедрений очень большой. Сегодня разумные директора крупных производственных предприятий как-то не спешат принимать решения о глобальной автоматизации, о постановке интегрированной системы управления предприятием.
Чем это обусловлено? Прежде всего, на мой взгляд, они не очень верят, что можно за такие большие деньги, за такие сроки получить управляемость предприятия. Во-вторых, в нашей стране ещё толком не урегулированы отношения собственности, и этот процесс будет продолжаться. И наконец, уровень ИТ-подготовки лиц, принимающих решения, пока очень невысокий. Более того, высший менеджмент, который действительно управляет предприятием, очень редко имеет и бизнес-образование и достаточный ИТ-опыт. И поэтому очень часто решение принимается на основании рекомендаций. В общем, налицо непрофессиональный выбор.
Николай Комлев. "РОЭЛ Консалтинг" помогает им как-то оптимизировать бизнес-процессы, сделать нужный профессиональный выбор?
Елена Ашарина. Да, у группы "РОЭЛ" в собственности есть предприятия; кроме того, она занимается и управлением, в том числе управляет чужими предприятиями. Ну и параллельно мы оказываем консалтинговые услуги.
Николай Комлев. То есть фактически вы можете выступить арбитром: сказать, что тут, например, нужно настроить систему, а тут перестроить бизнес-процесс у пользователя, да?
Елена Ашарина. Скажем, вот сейчас и в ОПК активно идёт процесс преобразований - это создание так называемых вертикально интегрированных структур. Разрабатывается система управления. И поскольку это касается в большей степени людей, то это всегда искусство, всегда очень сложный процесс согласований, взаимной увязки интересов разных сторон. Как тут можно говорить, что есть идеальная, замечательная какая-то система, под которую мы можем быстро прописать бизнес-процессы и их автоматизировать за год-полтора?
Кстати, чем больше масштаб проекта, тем больше и сроки. Мы должны быть уверены, что через эти полтора года у нас не изменится внешняя среда, не изменится потребность в новой модели управления. Но в наших сегодняшних условиях такое нереально. Я этим летом изучала опыт заводов Toyota, их системы управления. Вообще-то, я сама по сути бывшая программистка, "айтишница", и мне всегда казалось, что интегрированные системы управления - это гораздо лучше, чем какая-то лоскутная автоматизация. Вот почему меня очень удивил подход этой корпорации в части автоматизации. Поразило то, что последние 30 лет здесь принципиально не берутся внедрять большие интегрированные системы. И это Toyota, которая является лидером в автомобилестроении, именно по производству: у них самая низкая себестоимость производства и самая совершенная система управления; они не стремятся всё делать сами - у них тысячи субподрядчиков, поставщиков, и just-in-time у них на деле реализован, а не на словах. Более того, они берут свою модель управления, которую в Японии отлаживали в течение 50 лет, и переносят свои производства в Америку и пусть не за 5 лет, а за 10, но реализуют похожие и очень эффективные системы управления.
А американская автомобильная промышленность сейчас просто в нокдауне. Вопрос, может быть, десятка лет. Вот мы говорим: "Ах, какая замечательная у нас была ещё пятнадцать лет назад авиационная промышленность!" Так американская автомобильная промышленность сейчас примерно в том же положении. Она не очень конкурентоспособна по сравнению с японской, корейской. Так вот, возвращаясь к автоматизации: даже когда в 1980-е годы пошёл бум систем проектирования - AutoCAD, PiCAD, - тот же самый Форд, экспериментируя, закупил, по-моему, в общей сложности миллиона на два систем проектирования, прежде чем нашёл нужную. У него были неудачные варианты решений. Toyota же купила, наверное, лет на шесть позже систему автоматизированного проектирования, но именно ту, которая ей была нужна.
И сейчас здесь имеет место лоскутная автоматизация: они считают, что система не может управлять производством. Система - это средство, одно из средств, которое помогает учитывать, управлять, и поэтому её руководство стремится продумывать, находить, создавать для огромной корпорации оптимальные решения. Кстати, автоматизация очень часто заставляет как-то фиксировать бизнес-процессы, раз и навсегда "затверждать", не даёт двигаться дальше. Я, к примеру, увидела, что вот там "это" можно сделать быстрее, но у меня уже так "савтоматизировано", что сначала эта кнопка нажимается, эта процедура выполняется, потом - та, а потом уж только "нужная".
Николай Комлев. Вы правильно сказали, что даже если реализовать идеальную модель, то всё равно она стареет и дальше будет тормозить. А вы, ваша фирма, которая консультирует, наверное, можете помогать "подвинчивать" бизнес-процесс не только на предприятии, но и в системах у разработчиков, с которыми сотрудничаете?
Елена Ашарина. Конечно, конечно. Мы пытаемся. И, кстати, моё присутствие здесь как раз это доказывает.
Николай Комлев (обращается к Елене Ашариной). И всё-таки мне очень хотелось бы уточнить и понять место и роль консалтинга. Вы можете привести примеры взаимодействия с разработчиками?
Елена Ашарина. Пожалуйста. На одном из наших заводов в прошлом году начался процесс автоматизации всего предприятия. Решения принимались абсолютно волюнтаристские - президентом компании, который приказал менеджменту завода реализовать конкретное решение. Дальше сложилась такая ситуация. Допустим, я врач, у меня есть таблетки в сумке. Я прихожу к пациенту и говорю: "Примите мои таблетки". Пациент отвечает: "Таблетки пить не буду. Но я болею, так что давайте лечите меня". Здесь уже на начальном этапе считалось, что никакие консультанты не нужны, что всё совершенно ясно - с позиции лиц, принимавших решения (а это были владелец фирмы-разработчика и владелец завода). Мол, раз они договорились, менеджмент должен исполнить.
Но, к счастью, моими неимоверными усилиями удалось через некоторое время остановить проект - не довести его до большого скандала. Потому что месяца через три-четыре после начала проекта, к большому удивлению менеджеров, оказалось, что у них на предприятии нет системы управленческого учёта. Примерно месяца через три после начала проекта разработчики, точнее - внедренцы, поняли, что предприятию нужен не просто учёт, скажем, склада материалов, склада готовой продукции. Предприятию нужен производственный план. Прежде всего - план продаж, план загрузки оборудования, план оптимизации штатной численности под производственный план и т. д. И, кстати, сегодня, обходя выставку и беседуя со специализирующимися на производственных системах компаниями, я нужного решения пока не обнаружила - даже у ведущих компаний.
Сергей Алексеев (компания "ТБ.Софт", директор по продажам). У нас есть опыт работы с внешним консультантом. Один из заказчиков вначале провёл управленческий консалтинг, прописал управленческий план счетов, процедуры формирования управленческих проводок, статьи бюджетной классификации, регламенты бизнес-процессов, а потом выдал нам задание. Кстати, я совершенно согласен с необходимостью аккуратного употребления словосочетания "бизнес-процесс". Так вот, бизнес-процессов там практически не было - если понимать под этим термином регламентацию каких-то организационных процедур и схем документооборота. Там, в общем, шла речь примерно о том, о чём только что говорили, - о постановке управленческого учёта. Иными словами, об управлении бизнесами, консолидации, распределении финансовой ответственности, классификации затрат, процедурах разнесения затрат - таких вот задачах. Назвать это бизнес-процессами, по-моему, очень спорно, да и описать в нотации workflow трудно.
Игорь Якобсон (компания "Компас" (СПб), главный эксперт). Любое описание процедур того, что хоть как-то делается на предприятии, является описанием бизнес-процесса.
Андрей Орлов (компания "Росагролизинг", начальник отдела ИТ). Это скорее регламентация бизнес-процесса. Вообще, слово "реинжиниринг", конечно, очень красивое, но чаще всего речь идёт, на мой взгляд, не о реинжиниринге, а о минимальном описании и понимании того, что такое описание нужно.
Расскажу немного о своём опыте, который, правда, является "внутренним" - обычно я нахожусь "внутри" заказчика и обязан выступать с его стороны. Когда поступает заявка на автоматизацию, то я прежде всего пытаюсь вместе с клиентом описать технологию его работы. И зачастую оказывается, что никакая автоматизация не нужна, а требуется утверждённый регламент: кто за что отвечает, кто какие решения принимает, кто, что и в каких случаях должен делать. Как правило, такой документ отсутствует или содержит существенные пробелы. Если именно это называть реинжинирингом, то да, это вещь полезная, и она всегда нужна.
Но, к сожалению, на нашем рынке есть очень большая проблема с независимым ИТ-консалтингом. Я могу себе представить, что рядом со мной сидит представитель одной из независимых консалтинговых компаний. Но много ли по России консалтинговых компаний, которые обладают необходимым уровнем компетентности и порядочности, чтобы решать проблемы клиента, а не свои собственные, компаний, которые не аффилированы ни с каким разработчиком тиражируемых систем и не ангажированы программными решениями, находящимися у них в загашнике? Стало обычным делом, когда приходит консалтинговая компания, долго-долго проводит обследование и наконец говорит, что система Х - это именно то, что клиенту нужно, а потом выясняется, что система Х - это единственное, что они умеют внедрять. Вот тогда становится страшно.
Получается, что обязательно нужен внешний арбитр. С одной стороны от него находится руководитель, который считает, что у него всё хорошо, и требует, чтобы дали ему такую систему, которая вот именно так (через заднее место, извините), именно таким способом будет реализовывать бизнес-процессы. А с другой стороны - разработчик или внедренец, который с абсолютным апломбом говорит: "Да вы сотый (тысячный) клиент, который утверждает, что у вас ровно так, как у всех (или наоборот, всё уникально), а на самом деле у всех совершенно по-разному (или наоборот, почти всё одинаково)", а потом выясняется, что человек этот не знает даже, как происходит инвентаризация в магазине. Вот в этой ситуации, бесспорно, нужны консультанты. Но - независимые консультанты, умные, квалифицированные. А где они?
Николай Комлев. А такие бывают?
Андрей Орлов. Одного нашёл.
Николай Дерябин. Получается, на один "независимый консалтинг" надо иметь ещё один - более независимый.
Игорь Якобсон. Так как очередь на выступление доходит редко, у меня возникла идея - ответить на вопросы почти в телеграфном стиле "да - нет", вернувшись к вопросам раздела 2. Итак, кто и как принимает решения о реинжиниринге бизнес-процесса на предприятии? Только заказчик, поскольку роль консультанта (как по ИТ, так и по бизнесу) заключается только в подаче предложений. Далее. Как происходит распределение ответственности между исполнителем и заказчиком? Исполнитель отвечает за точное исполнение подписанного ТЗ, будь то ТЗ на реорганизацию или описание реорганизованного бизнес-процесса или на адаптацию ПО.
Реплика из зала. А если ТЗ кривое? Подписал - "сам дурак", да?
Игорь Якобсон. Вот этого не надо: тебя никто не тянул, и обсуждалось оно сто раз. А если ты - заказчик и ещё, видишь ли, не хочешь принять участие даже в рассмотрении и подписании ТЗ...
На минутку отвлекусь. Мы тут получили на пяти страницах пожелание от клиента. У нас просто праздник был. Пять страниц они написали! Господи! Это ж песня, знаменательное событие!
Идём далее. Насколько реинжиниринг экономически оправдан для заказчика и для внедренца? Для заказчика бывает "оправданность". Для внедренца - если у него не "пролётный" финансовый директор - оправдан всегда. Существует ли реальная ответственность за убытки, которое может понести предприятие? Не знаю примеров, кроме страхования рисков по внедрению ИТ, и то только на Западе, хотя у нас тоже что-то об этом говорили. Не знаю даже, чтобы на Западе финансовую ответственность нёс внедренец, консультант, разработчик.
Николай Комлев (обращается к Елене Ашариной). У вас тоже нет этой практики - в плане страхования ответственности?
Елена Ашарина. Страхования по проектам нет.
Игорь Якобсон. Я слышал, что кто-то у нас пытался внедрять страхование рисков. Но очень тяжело описать все условия, определить, когда вина внедренца, а когда - заказчика. Ну, блока моделирования бизнес-процесса в "КОМПАСе" пока нет. А кому он нужен? Скорее исполнителю; может быть - консалтинговой фирме. А вот заказчики, которые были бы в плане ИТ на нашем уровне, - таких на нашем рынке не знаю, причём я говорю о реальных заказчиках. Просто не верю.
Осталась пара вопросов по разделу 3. Место консалтинговой компании - посредник, партнёр или генподрядчик? Нет, не генподрядчик, потому что, когда мы работали с заказчиком, где в качестве генподрядчика выступала консалтинговая компания, она уже на первой стадии проекта самостоятельно (без нашего участия) реализовала обследование бизнес-процессов, и потом нам пришлось практически всё переделывать. Причём пришлось хитрить и вести дополнительное обследование полулегально и, в сущности, за свой счёт, потому что клиент, естественно, за повторное обследование платить не хотел.
Существуют ли "нейтральные" бизнес-консультанты? Я таких не знаю и знать не могу. Даже когда в 1998 году я подробно знакомился с работой такой знаменитой на тот момент фирмы, как "Андерсен Консалтинг", ныне почившей в бозе, выяснилось, что там знают только два продукта, причём один из них - плохо. И всегда предлагают фактически один программный продукт, достаточно известный, так что не будем его называть.
Ну и последнее - это уже просто для разрядки - к вопросу о том, осознанно или неосознанно принимают наши высшие менеджеры решения о внедрении. Вот тут упомянули, что кто-то сделал это по рекомендации, по совету, и я подумал: "О, в этом мы почти догнали Америку, на которую частенько ориентируемся". В 1998 году я встречался с владельцем консалтинговой американской компании, которая занималась исключительно внедрением систем J. D. Edwards. Это была небольшая компания: там в штате не более 10 консультантов, но в Новой Англии, например, они участвовали в автоматизации всех центров обслуживания Toyota. Я спросил, как его заказчики - а у него хорошие, солидные клиенты - выбирают системы и принимают решения. "Есть два проверенных и надёжных способа, - сказал он. - За основу берётся мнение партнёров по гольф-клубу и мнение соратника по студенческой лиге". И третий способ: читать хороший, модный тематический журнал, причём журнал предельно, скажем так, научно-популярный, причём больше "поп", чем научный. Так что зря мы порой так уж превозносим западный стиль ведения бизнеса. И там всякое встречается.
Евгений Валкин. Я попытался поставить себя на место бедного клиента - не в смысле его финансов, а потому что перед ним весьма непростая задача. С одной стороны, у него есть компания, которая его автоматизирует (потенциально или фактически), а с другой - теперь появилась консалтинговая компания. Каков же может быть алгоритм его действий? Первое, с чего он вроде бы должен начать, так это работать с консалтинговой фирмой. Представим себе, что некая независимая консалтинговая фирма, о которой мы здесь все мечтали, выдаёт заказчику совершенно замечательный, но абстрактный бизнес-процесс его деятельности, который вроде бы должен быть оптимальным. Что ему делать дальше? То ли искать программу, которая под этот совершенно абстрактный процесс подходит больше всего, то ли создавать своё решение. Получается, что если первой пошла "совершенно независимая" консалтинговая фирма, то ему обязательно придётся заказывать разработку индивидуального проекта под этот бизнес-процесс, потому что вряд ли какая-либо программа на рынке точно может подойти для автоматизации уникального бизнес-процесса, который для серьёзной компании, в общем, достаточно сложен. Не совсем понятно, что в этом случае практически делать клиенту.
Игорь Якобсон. Можно ответить очень коротко. Я только что статью на эту тему писал как раз в "БиК".
Я предлагаю в этой ситуации следующий алгоритм, который вряд ли может быть реализован на практике в большинстве случаев. Нанимая консультантов, необходимо отчётливо представлять себе, что обследование будет делиться на два этапа. Первый этап - общее описание бизнес-процессов - действительно может выполнить бизнес-консультант, после чего он должен быть изолирован, начисто отстранён от проведения тендера закупок программных продуктов: их необходимо закупать самостоятельно. Результат первого обследования (консалтинговой фирмы) выдаётся ИТ-фирме, далее проводится ИТ-обследование. ИТ-фирма должна суметь обработать и объединить результаты обоих обследований: используя их, снизить стоимость и оптимизировать функциональность проекта.
Сергей Проскурин. Я как представитель, так сказать, нетрадиционной ориентации в этом кругу хотел бы высказать одну мысль. Евгений, вот вам не жалко того неизвестного клиента? На мой взгляд, одна из главных ошибок тех заказчиков, которые хотят заказать проект под себя, состоит в том, что они видят его конечным. Проект по автоматизации - как ремонт: его можно начать, но нельзя закончить. И если заказчик будет на это смотреть трезво и знать, что он затратит, скажем, несколько десятков тысяч (а крупные - так и сотен тысяч) долларов на текущий год на процедуры обследования, выработки ТЗ, частичной автоматизации и дальше ежегодно будет закладывать в свой ИТ-бюджет соответствующие суммы, достаточные для поддержания современного уровня автоматизации, и активно работать с этой же фирмой-разработчиком и одновременно доводить и свои процессы управления, и продукт, помогающий их овеществлять, то тогда, я думаю, этот заказчик получит хороший реальный результат и будет действительно доволен. Потому что заблуждение и надежда на то, что можно один раз и навсегда всё автоматизировать и после этого разработчик (как тот мавр) может уходить, а заказчик останется один на один со всем хозяйством - это, конечно, нелепо, но прозвучало уже неоднократно. Жизнь идёт, всё меняется, поэтому взаимодействие должно быть постоянным.
Но есть и другой вариант: заказчик может прекратить своё существование из-за того, что уже не встанет после такого проекта.
Евгений Валкин. Всё-таки отвечу. Я пытался изобразить потуги клиента в предположении, что он сначала выбирает независимую консалтинговую фирму. На мой взгляд, если фирма, которая разрабатывает программу, не может провести достаточный консалтинг именно по отношению к своей системе (годится она для данного предприятия или нет, насколько годится) и полностью решить проблемы клиента, то такая фирма просто не подходит заказчику. И вообще, первый этап для меня не совсем понятен: в целом работа консалтинговой компании ясна, но когда та же компания занимается фактически формулировкой необходимых условий для выбора программы - для меня это уже непонятно, потому что для каждой программы требуются глубокие знания технологии её работы, её специфики, её возможностей. Та фирма, которая разрабатывает главные требования, должна и сформулировать, смоделировать, как будут реализовываться, изображаться, действовать эти бизнес-процессы для заказчика, и сама же должна внедрять так, как это необходимо самому заказчику. Ну, речь идёт, конечно, о крупных заказчиках. Для небольших - уже по-другому.
Сергей Проскурин. Евгений, вы говорите об этапе выбора разработчика, внедренца. А я о другом. Я хочу сказать, что практически любой здравомыслящий разработчик удовлетворит любого заказчика, если они будут "как супруга" подбирать друг друга, т. е. рассчитывая жить вместе долго.
Реплика из зала. Сергей Павлович, это уже по-другому называется, это "аутсорсинг".
Сергей Проскурин. А вот, к примеру, швейцарские банки отказались от использования для этих целей своего персонала, обратились к известной аутсорсинговой фирме, которая консультировала их, подбирала и внедряла для них соответствующую систему автоматизации управления. Вот такие фирмы будут всё более востребованы, и решение "проект под клиента" будет внедряться в такого рода фирмах.
Евгений Валкин. Относительно того, что "любая фирма удовлетворит": есть такие случаи, когда, скажем, требуются большие "ответвления" и доработки типового решения, которые нужны для реализации специфики деятельности данного предприятия. Конечно, может быть, и "любая фирма удовлетворит", но удовлетворит за пять лет; к тому времени уже вполне возможно, что и компании заказчика-то не будет.
Николай Комлев. Я знаю, кто может высказаться по этому поводу. Владимир, любая ли программа или фирма удовлетворит клиента?
Владимир Мицкевич (эксперт). В настоящее время - если это фирма Проскурина и программа plug-and-play (и тем более "Гусарик"), то, конечно... Ставь программу - и работай.
Я, как мультивендорщик, неплохо знакомый с основными лидирующими российскими системами, старейший соратник этого клуба, могу высказать определённое мнение, не привязанное к какой-либо платформе и не лоббирующее ничьих интересов.
Если говорить о бизнес-процессах как об основе нормальной деятельности предприятия, то, во-первых, они, как правило, не описаны. Нет положений ни о коммерческой политике предприятия, ни об организации бизнес-процессов. Они все - в головах наших заказчиков, поэтому не описаны и не формализованы. О какой постановке реинжиниринга может идти речь, когда они должны ставиться и формализоваться на уровне регламентных документов!
Далее. Абсолютно правильно коллеги говорили здесь, что есть функциональность системы, а есть бизнес-процессы. Пытаться систему натягивать на бизнес-процессы - это смертельно. Иначе говоря, фактически есть система с некоторой функциональностью, эта функциональность поддерживает какие-то бизнес-процессы, какие-то, возможно, нет. Мы недавно проводили ряд пилотных внедрений, и возникла следующая ситуация. Базовый проект мы ориентировали на функциональность и проводили его экспертизу - на предмет охвата функциональностью их бизнес-процессов, - поскольку, пока делаешь проект, бизнес-процессы могут сто раз измениться. Но базовая функциональность программного обеспечения, заложенная с избыточностью, аналитичностью и пр., должна их поддерживать. Поэтому базой любой системы является её функциональность. Если мы влезем в постановку бизнес-процессов при внедрении системы, нас там всех и похоронят. В общем, мы согласуем со всеми группами персоналий функциональность системы, а в каком порядке и что там (на предприятии) делается - это неважно. Сегодня они сначала выписывают счёт, потом - накладную, а завтра - наоборот. Сегодня они согласуют цены с бюро цен, а завтра строят ценовую политику на основе электронных тендеров. Сегодня имеется возможность дать скидку в 5 %, а завтра предлагают чуть ли не за любую цену - лишь бы продать. Сегодня ориентируются на собственное мнение, завтра - если "дебиторки" нет. Всё это должно быть описано в том, что называется коммерческой политикой предприятия, порядком бизнес-процессов. Всё это должно ставиться и формализоваться на фирме, а мы должны представить достаточную функциональность, которая позволила бы им организовать бизнес-процессы так, как они считают нужным на сегодняшний день, и поддержать их изменения базовой функциональностью.
Теперь следующее. Абсолютно правильно здесь коллеги говорили о том, что бесполезен так называемый управленческий предваряющий консалтинг, который будет составлять требования к какой-то абстрактной информационной системе. ИТ-консалтинг чётко привязан к функциональным возможностям и терминологии выбранной базовой системы. Поэтому ИТ-проект на внедрение будет чётко ориентироваться и опираться на базовые возможности программного продукта и пытаться трансформировать их для покрытия неких бизнес-процессов функциональностью внедрения. Работа бизнес-консультанта без привязки к базовым возможностям информационной системы - это так, вилами по воде, это ни о чём.
Елена Ашарина. Если следовать аналогиям, то вы говорите про магазин готового платья, куда приходишь и говоришь: "Мне сорок четвёртый, ему - сорок восьмой"...
Владимир Мицкевич. Извините, я не говорю о магазине готового платья, я говорю, что любая система должна иметь достаточный набор функций: скажем, выписывать счёт, счёт-фактуру, накладную, резервировать товар на складе, регистрировать договор и пр. А в каком порядке и в каких регламентах они будут использоваться - это уже непринципиально. На разных предприятиях это может быть реализовано по-разному.
Андрей Орлов. Это на здоровье, только вы ещё говорите, что техническое задание будете описывать в терминах своей системы. Нам, например, это совершенно не нужно.
Владимир Мицкевич. Отвечу: не в терминах системы. Кто может знать все эти терминологии! Видите ли, есть представление фактического результата клиенту, но есть и базовая терминология структуры. Мне довелось участвовать в проекте SAP и переводить их терминологию PriceWaterhouseCoopers для "ТНК-BP" в формат "Паруса". В результате пришлось сильно потрудиться и отказаться от ряда вещей. К примеру, в концепции базовой системы SАР имеется так называемая разорванная проводка, с пробными балансами, ну и прочими радостями. В настоящее время всё это должно быть заложено как описанная функциональность, и делать то, о чём мы говорили по теме сегодняшнего "круглого стола", т. е. "натягивать" клиента на организационно-базовую концепцию системы, всё равно придётся, в том или ином объёме. Другой вопрос: открытость платформы, параметрические настройки и прочее позволяют пересмотреть некие возможности, уровни аналитики и другие вещи, но в подавляющем большинстве случаев взаимонастройка (исполнитель - заказчик) всё же неизбежна. Просто тот, кто отстаивает параметрические системы, рассказывает, что в них это намного лучше делать, чем в исходных кодах. Те же, кто отстаивает открытые системы, которые позволяют не только разработчикам, но и сторонним программистам прямо в кодах править программы, рассказывают, что это лучше совершать в кодах. Неважно как - в кодах или в параметрических системах, но всё равно должна иметься возможность "взаимонастройки сторон". Однако закрытые параметрические системы имеют значительно меньше возможностей, чтобы пойти навстречу клиенту, поэтому в любом случае клиент "натягивается" на конфигурацию и базовую концепцию системы. И реализаторы системы по мере заложенных в ней возможностей по адаптивности и учитывая бюджет клиента идут последнему навстречу. Это по второму вопросу.
Теперь о месте консалтинговой компании. В стратегии фирмы, в целеполагании, в командообразовании, в базовых её компетенциях они (консультанты) слабо влияют на ИТ-проект. Консалтинг имеет семнадцать направлений деятельности - и всё это действительно консалтинг. Очень многие злоупотребляют этим вопросом. Потому что, если бы консалтинговая компания описала организацию бизнес-процесса, составила схему документооборота, обязанности всех людей и пр., то ей бы цены не было.
Елена Ашарина. Кстати, вы говорили, что работали на "РОЭЛ". Ну так вот на предприятиях "РОЭЛ" стоят большие шкафы и полки с документами, где описаны все эти процедуры, регламенты. Правда, жалко, что ими тоже не пользуются, они не подкреплены автоматизацией.
Владимир Мицкевич. Уточняю насчёт внутреннего документооборота "РОЭЛ" и его предприятий: я это уже видел. Если место и роль консалтинговой компании в том, что они пропишут и упорядочат до нас то, что называется коммерческой политикой (положение о бухучёте и управленческом учёте, положение о бизнес-процессах), и пропишут все документообороты, и все на местах начнут работать как положено сначала вручную, в опережение информационных систем, то тогда наши информационные системы воспримутся как панацея для облегчения их деятельности.
Вот место консалтинговой компании... Но очень желательно, чтобы в их проектах было меньше воды, псевдонауки и лирики, а больше конкретики.
Алексей Нестеров. Я бы тоже хотел высказаться по поводу места консалтинговой компании, предложить свои наблюдения от фирмы "1С".
На мой взгляд, сейчас позволить себе чисто консалтинговую фирму для реструктуризации бизнес-процессов, а потом другую фирму для выбора ИТ-решений, а потом ещё третью для их внедрений могут только очень немногие компании из представленных на российском рынке. У этих компаний нет необходимости решать какие-то срочные, актуальные производственные задачи или задачи, которые возникают в связи с конкурентностью. Эти компании могут позволить себе полгода-год прописывать бизнес-процессы, полгода выбирать ИТ-решение, а потом года три его внедрять и пр. Мы, работая сегодня на среднем и крупном рынке, чаще сталкиваемся с ситуацией, когда уже идёт этап выбора ИТ, когда предприятия вплоть до уровня высшего руководства, сначала решают вопрос выбора платформы, будь то SАР, Oracle, "1С", Microsoft SQL и т. д., а уже потом они выбирают консультанта, который на этой платформе сможет реализовать их задачи, их потребности. И выбор решений уже идёт на какой-то конкретной платформе из нескольких вариантов...
Николай Комлев. Разве так бывает? Правда ли, что директора предприятий сначала думают о глобальном выборе платформы, как бы класса систем, а потом уже - как и кто будет это реализовывать? И затем приглашают консультанта, причём консультант здесь существенной роли не играет?
Реплика из зала. Конечно, по стоимости системы и по проценту отката...
Алексей Нестеров. Стоимость крупной системы по большей части является основополагающим критерием. Руководство определяет, какие у него цели: увеличить капитализацию, выйти на IPO - это один выбор. Или в течение года решить актуальный вопрос с незавершёнкой, с планированием производства, прикинуть, где оно деньги потеряет, - это может быть другой выбор. От этого может зависеть и выбор платформы, её стоимость и сроки внедрения. Вот после этого идёт как раз выбор консультанта. Это может быть консультант мультивендорный, может быть одновендорный. Уже здесь, на этом этапе, происходит выбор его компетенции.
И, кстати, это же подтверждает статистика. По опубликованным данным (по-моему, "Эксперта"), ИТ-консалтинг показывает сейчас наибольшую динамику роста. У традиционных консультантов динамика замедлилась, и их рост сравнился с ИТ-консалтинговым.
Николай Комлев. Значит, не консультант "приводит за руку" ту или другую свою знакомую систему, а как раз наоборот получается?
Алексей Нестеров. Вот это в основном было раньше. Несколько лет назад было довольно мало нормальных, серьёзных продуктов. И тогда предприятия действительно не знали, что им подойдёт. Тут нужен консультант, который разберётся, что-то порекомендует, будет нести за это ответственность. Сейчас же, когда на рынке представлено довольно большое количество качественных программных продуктов, фактически любой из них при грамотном и добросовестном подходе может дать отдачу предприятию. Вопрос - в какие сроки, за какую цену и кто это сделает. Поэтому сегодня уже проще не брать консультанта, чтобы он в результате рекомендовал конкретную систему, ту или иную платформу, а вначале выбрать платформу, а потом на основе её уже определяться с бизнесом. И уж если с помощью этой системы, платформы задача не решается - перейти к следующему этапу (например, провести специальные доработки) или, в крайнем случае, выбрать другую платформу. То есть экономически это бывает более целесообразно, и сегодня это можно сделать в более короткие сроки, чем всё абсолютно точно, тщательно и долго обследовать, примерять и рассчитывать, а потом только выбирать из всех возможных вариантов какие-то платформы, системы.
Владимир Пичугин. В общем, соглашусь с Алексеем.
Игорь Якобсон. Один вопрос... и замечание. Меня более всего поразило, что сначала выбирается платформа, потом - ИТ-консультант, т. е. внедренец. В жизни с этим не сталкивался, и скажу даже более конкретно: в жизни не видел, чтобы предприятие было настолько неразумно, чтобы, выбрав платформу, - скажем, той же фирмы "1С", - не выбрало франчайзера (внедренца). То есть в тех тендерах, что мы участвовали, каждая система всегда была представлена конкретным франчайзером (для "1С", возможно, даже не одним), и заказчики выбирали предлагаемую систему, платформу только вместе с ним. Потому что от этого зависит всё. А теперь действительно существенный вопрос. Кто-нибудь когда-нибудь видел, слышал, "нюхал" - не знаю, как ещё сказать, - чтобы консультант за что-то отвечал?!
Реплика из зала. Платят хорошо, а ни за что не отвечаешь.
Владимир Мицкевич. Коллеги, извините; здесь надо различать, что такое консультант, их порядка семнадцати видов. Есть бизнес-косультант: это стратегия, целеполагание, кадровая политика и т. п. Есть ИТ-консультант. ИТ-консультант говорит: "Я не знаю слов любви, зато я знаю, как автоматизировать ваши бизнес-процессы".
Николай Комлев. А кто такой ИТ-консультант - это внедренец конкретной системы или это аутсорсер какой-то?
Владимир Мицкевич. ИТ-консультант - это, "по-старому", чистый внедренец, который, обследовав предприятие, говорит: "На вашем предприятии бизнес-процессы построены так; по опыту других моих внедрений я их рекомендую немножко перестроить, чтобы не было криво. И я вам внедрю комплексно вот это решение". Поэтому Алексей Нестеров правильно сказал: прежде чем организовывать тендер, большинство предприятий, компаний оценивают свои возможности и уровень претензий. Выбирают вначале ценовой уровень систем, скажем, это SАР, Axapta, "1С". Иначе говоря, пока клиент не заглянет в свой бюджет и не поймёт, какой ценовой уровень будущей системы его устроит, скажем, по 15 тыс. долл. за место пользователя, по 8 тыс. или по 2 тыс., включать механизмы выбора франчайзера и уточнять пороги, ограничения и функциональность бесполезно. Если его бюджет будет неограниченным - 1,5 млн долл., 500 тыс., 200 тыс. для него всё равно, - то можно и сначала смотреть на характеристики систем. Поэтому мы в последнее время всё больше сталкиваемся с ситуацией, когда фирма говорит: "У нас во всех "дочках" в структуре холдинга аналитической программой будет "1С"", - и обращается к Алексею Нестерову, который располагает всей сетью центров компетенции. Он отбирает пять-шесть-семь партнёров, "заточенных" именно под такие вот решения, и организуется микротендер для окончательного выбора заказчиком фирмы-внедренца. А устраивать какие-то пляски с бубнами вокруг Oracle, SAP, Axapta, "1С" и т. д. - это просто несерьёзно или тогда это какие-то замыслы, для нас непонятные.
Андрей Орлов. Как мне представляется, вы сейчас искажаете картину, причём вполне умышленно. Никто, конечно, не сравнивает SАР с "1С", но кроме SАР имеется, например, Baan, т. е. существуют системы одинаковых стоимостных ниш, и их не одна, а, слава богу, по нескольку. А вот если взгляд такой, что выбирать можно исключительно между SАР, Axapta и "1С", то непонятно, что мы тут обсуждаем.
Николай Комлев. Чтобы все понимали, что мы тут далее обсуждаем, мы просто плавно, по времени и по вопросам переходим к четвёртому разделу нашего "круглого стола". Здесь будут вопросы изменения проекта, приоритета и выбора.
Раздел 4.
Изменения проекта, технологий, изменение потребителей.
Кто или что меняется быстрее?
Кто чаще является инициатором изменений ТЗ, вариантов проекта, версий систем (если исключить влияние Минфина) - разработчик или потребитель?
Как изменились заказчики (клиенты) за последние 5-7 лет?
Что стало больше влиять на их приоритеты, их выбор: мода, стоимость, капитализация, откаты, интересы бизнеса?
Как часто стали приобретать систему, основываясь на оценке перспектив развития бизнеса?
Чему (кому) чаще отдаётся предпочтение: системе или команде?
Николай Комлев. Вот теперь, Владимир, продолжайте, возражайте, но очень коротко.
Владимир Мицкевич. Изменение проекта технологий и изменение потребителей. Если изменение проекта повлечёт за собой ситуацию, когда клиент окажется "на ИТ-игле" и по каждому чиху надо будет что-то менять, то в ряде случаев мы отказываемся от изменения проекта в целях возможности его индустриальной поддержки. Поясню, что имеется в виду. Скажем, Бакаев создал план счетов, для отчётности. У нас есть индустриальная поддержка своих систем, решений. Если клиенты придерживаются неких наших требований и методических рекомендаций при работе с системой, то мы для них поддерживаем индустриальное обновление законодательства. Если же они собираются менять какие-то вещи или что-то полностью перекраивать...
Николай Комлев. То есть если вы сами туда залезли, то сами и вылезайте?
Владимир Мицкевич. В системе есть определённые возможности, например, даны методология и требования работы с субконто и т. п., можно залезть и что-то менять. Но - в рамках рекомендаций методического отдела фирмы, и тогда мы это будем индустриально поддерживать. Если же вы произвели изменения, выходящие за установленные рамки и чреватые последствиями при индустриальной поддержке, то тогда извините. Не потому, что тяжело переписать код, а потому, что потом надо его поддерживать для огромной массы пользователей. Вот отношение к изменению проекта и технологии его изменения потребителем при изменении деятельности предприятия.
Алексей Корявко. Мы здесь пообсуждали, как и что лучше выбирать - систему, консультантов, и с чего начинать ИТ-проект. Поговорили и о стандартах. Владимир Мицкевич чудесным образом нам объяснил, что есть бизнес-процессы и что с ними надо делать, но вот я хочу рассказать, как это всё в жизни происходит.
Одна очень уважаемая информационная компания поставила один такой проект, (назовём его программой А), другая, не менее уважаемая фирма внедрила в этой же компании другой проект (назовём его программой Б), связанный с интернетом. И вот получилась какая-то гремучая смесь из этих самых технологий. Звонят из компании, которая поддерживает интернет-сайт: "У нас проблема с этим самым сайтом". Сотрудники "засовывают" некую информацию в программу А, которая жужжит минут 30, после чего "выплёвывает" цифирь. Потом человек выписывает эту цифирь на бумажку и засовывает её в другую, не менее уважаемую программу Б. Та ещё минут 40 жужжит. Спрашиваем: "Ребята, отчего у вас так? Это что, корпоративный стандарт? Кто вас так консультировал и какая фирма это всё вам напроектировала?" А второе, что нас тут интересует, - как раз по вопросу организации и "стандартизации" процессов. Разработчики на это отвечают: "Накладная стандартной формы есть? Есть. Выписывается? Выписывается. Работает? Работает. Что вам ещё надо?" А как с этим работать, если вы должны нажать 155 кнопок и ещё чего-то там запомнить в уме или на бумажке записать, - это совершенно другая проблема. Поэтому, мы какую проблему сейчас обсуждаем? То, как нужно прописывать бизнес-процессы, или то, как лучше их реализовывать? Клиенту что нужно - чтобы было всё прописано, или чтобы нормально работало, или чтобы он просто как-то участвовал в процессе, придуманном консультантами?
Игорь Якобсон. Хоть ты тресни, вот я читаю четвёртый раздел темы - нет там этого.
Николай Дерябин: Можно пару слов сказать в качестве представителя заказчика? Тут будут затронуты вопросы и второго, и четвёртого раздела. В принципе заказчику важно что? Чтобы был достигнут конкретный результат. И вот когда речь идёт о перспективах, которые должны просматриваться и закладываться уже сейчас, то представители тех же американских IBM, InterSystem говорят, что в их договорах предполагается заложить (пока этого ещё нет) принцип конкретной реализации бизнес-модели, приводящий к положительному результату (эффекту). Если эффект не достигается, деньги возвращаются или не выплачиваются. Вот таким образом они предлагают строить договорные отношения.
Николай Комлев. А кто будет арбитром и что именно в результате этого будет получено?
Николай Дерябин. В договоре, видимо, планируется конкретно сформулировать и обозначить ближайшие и перспективные цели, пути их достижения, условия, экономические параметры, положительные эффекты, которые должны быть достигнуты. Для каждого этапа проекта эти цели, условия, параметры могут быть свои, и соответственно уровни затрат и ресурсов по этапам могут быть разными. Например, достигнуты ли в системе управления предприятием, проектом повышение управляемости, оперативность, оборачиваемость, производительность, технологическая дисциплина, отдача и пр. Скажем, упала прибыль или увеличилась. Но эти параметры совсем не обязательно должны быть чисто экономическими.
Реплика из зала. Это зависит от эффективности работы самого предприятия.
Елена Ашарина. Между прочим, консультанты очень часто именно по такой схеме и работают с клиентами, если уж на то пошло.
Николай Дерябин. Я задал вопрос одной из ИТ-фирм, нашей фирме: "Кто описывает у вас технологию работы на предприятии?" Отвечают: "Как кто? Заказчик". Я спрашиваю: "А как же вы будете считать - из-за кого тот или иной положительный эффект достигнут?" Они отвечают: "Ну, мы не знаем как". Я ещё говорю: "А ваши американские партнёры, которые дают вам продукт, говорят, что это будет так..." Представители этой фирмы говорят: "Они нам подскажут". Понимаете? Но, во всяком случае, представители вышеназванных корпораций заявили, что это будет делаться так. Как это будет выглядеть на самом деле - не знаю.
Реплика из зала. Это всё реклама.
Николай Дерябин. И второе - когда сказали о сроках. Конечно, сам процесс автоматизации может быть очень долгим, но договор всегда имеет конкретные рамки. Что считать определённым этапом в договоре, вполне можно оговорить и подвести какие-то итоги. А следующий этап может быть уже прописан в следующем договоре.
Николай Комлев. Хорошо, идём дальше.
Игорь Якобсон. Идём по вопросам. Кто чаще всего является инициатором изменения ТЗ, проекта - разработчик или потребитель? Потребитель, потому что разработчик составляет ТЗ, а потребитель его меняет. Покажите мне потребителя, который сам составит ТЗ, - и всё будет наоборот. Как изменились заказчики и клиенты за последние 5-7 лет? У нас "нечистый" эксперимент, соответственно и нет ответа на этот вопрос, потому что мы, как иногда выражаются, меняли ориентацию на рынке. У нас они (заказчики) укрупнились. В целом я думаю - тоже, судя по тенденциям экономики в стране. Следующий вопрос: что станет больше влиять на их приоритеты? На их выбор? Так вот, в условиях растущей монополизации (а я считаю, что это так) и отчуждения непосредственного владельца от бизнеса откаты стали играть б€ольшую роль. Это естественно. Это просто входит в условия сегодняшнего российского рынка и менталитета...
Николай Комлев. Вроде рынок-то цивилизованный?
Игорь Якобсон. Десять лет назад из наших клиентов больше контролировали процесс владельцы бизнеса, они и принимали решение. Сейчас это чаще высшие менеджеры, которые владельцами не являются. А деньги им нужны позарез, причём всегда.
Теперь про стоимость. Стоимость, слава богу, как кажется, стала играть меньшую роль, она ушла с первых мест таблицы критериев. Она, конечно, остаётся по-прежнему важным критерием, но сдвинулась вниз по шкале акцентов. Капитализация и интересы бизнеса остались примерно в прежних пропорциях, потому что по-прежнему многим нужны западные инвестиции, и тогда капитализация важна. Многие хотят развивать бизнес здесь, в России, значит, здесь важнее интересы бизнеса. Как часто стали приобретать систему, основываясь на оценках перспектив развития бизнеса? Ну, в общем, если судить по их словам - то чаще. Чему, кому чаще отдаётся сегодня предпочтение: системе, команде? Только системе с командой. То есть - не разрывая. Я сужу по тому, как принимаются решения, я смотрю, как и какие вопросы мне задают на переговорах. Примерно равная пропорция: заказчики пытаются прощупать, оценить фирму как таковую, команду и в той же мере - функционал и настроечные возможности системы. Тут абсолютно одинаково, они не отрывают систему от команды.
Евгений Валкин. В наших условиях, при очень высокой рентабельности многих крупных предприятий, по крайней мере, по нашим заказчикам в основном совершенно всё равно. Главное - не суетиться, ничего не менять ни в бизнес-процессах, ни в ТЗ. Если клиентов серьёзно ничто не тревожит, они вообще ничего менять не будут. Если отвечать на вопрос, кто чаще меняет, то замечу, что иногда клиенты выдумывают совершенно невероятные фантазии - просто невероятные, которые нормально описать почти невозможно и которые с огромным трудом перекладываются в наши же программы. Потом они опять что-то меняют, добавляют, поправляют. Некоторые фантазируют без удержу: если уж пошла "фантазия", её сдержать трудно. Но если рентабельность высокая, они стараются вообще не трогаться с места, на котором стоят, и на этом месте остаются.
Владимир Пичугин. Я с третьего пункта начну - место консалтинговой компании. Я тут поддержу тех, кто сказал, что консалтинговая компания не может заниматься даже описанием бизнес-процессов. Мы с таким сталкивались. Консалтинговая компания выступает в своих интересах, она отстранённо описывает что-то. Но когда начинается внедрение, то внедренческая компания опять начинает обследовать, анализировать и по-своему делать описание бизнес-процессов, поскольку она их должна положить на совершенно конкретную систему. Если мы опишем некий абстрактный бизнес-процесс, то действительно сложно будет предложить какую-то подходящую систему, поэтому тут консалтинговая компания, в общем-то, не помощник.
Есть ли "нейтральные" консалтинговые компании? Я не встречал, не видел, не знаю. Как правило, консалтинговая компания рекомендует ту систему, которую она имеет "за плечами".
Кто берёт на себя роль генподрядчика - консалтинговая компания или разработчик? Упаси бог, чтобы генподрядчиком выступила консалтинговая компания. Потому что если будем проект, систему сдавать консалтинговой компании, то сдать-то мы ей сдадим, но сможет ли работать клиент? Скорее всего - не сможет.
Чьим заложником является клиент - разработчика, внедренца? На самом деле - разработчика и внедренца. Ну и консалтинговой компании, если по каким-то другим вопросам, но не по внедрению системы.
Теперь вопрос об изменениях проекта, технологии: кто меняет и что меняется быстрее? Тут, как я понимаю, вопрос стоит об изменении ТЗ в ходе проекта - это основная проблема. Действительно, согласованные и уже подписанные сторонами ТЗ в ходе проекта нередко начинают меняться. Естественно, инициатором таких изменений является заказчик, и, конечно же, не в интересах разработчика, внедренца это делается. Это почти всегда только в интересах заказчика. Когда заказчик внедрил, освоил, узнал что-то, он только тогда увидел и понял, что вот так будет, на его взгляд, ещё лучше. Когда он смотрел на это абстрактно, теоретически, со стороны, ему казалось, что так будет нормально. А после того как немного поработал, то понял, что по делу будет лучше-то вот так...
Елена Ашарина. Как далеки вы все от народа!
Владимир Пичугин. Мы реально внедряем системы, и в основном клиенты довольны.
Николай Комлев. Давайте дадим Владимиру Пичугину договорить, потом ещё один человек, и всё.
Владимир Пичугин. Теперь о том, как изменились заказчики за последние 5-7 лет. В основном они стали больше, укрупнились, стали более сложными сами структуры и объекты автоматизации и требования к ней. Если раньше система нужна была в основном учётная, то теперь упор делается на управление бизнесом. Если раньше бухгалтерский учёт ставился во главу угла, то сейчас на него обращают внимание далеко не в первую очередь. "Стоит у нас какая-то бухгалтерская система - да и пусть себе стоит".
Николай Дерябин. А в плане знаний?
Владимир Пичугин. В плане знаний - выросли. Как правило, существенно выросла квалификация людей, принимающих решения.
О мотивах принятия решений и так называемых откатах. После принятия решения, возможно, где-то имеют место откаты, вероятнее всего, в крупных компаниях, но уже после принятия решения.
Николай Комлев. Последний выступающий.
Алексей Нестеров. Думаю, присутствующим интересно будет узнать данные маркетингового исследования фирмы "1С". Сейчас программный продукт на новой платформе "Управление производственным предприятием 8.0" используют уже около восьмисот клиентов. И по первым пятистам клиентам мы собрали очень подробную статистику, причём партнёры опрашивали клиентов, их степень удовлетворённости, анализировали сроки внедрения и т. д. и вывели определённую закономерность. Понятно, что все внедрения удачными не могут быть: у нас, по опросу партнёров, порядка 3 % неуспешных внедрений. Официальные данные будут скорее всего представлены в пресс-релизе по итогам партнёрского семинара.
И вот мы более внимательно проанализировали, проанкетировали клиентов по поводу того, почему эти проекты не удались. В 29 % случаев неудовлетворённость возникает как раз при изменении проекта в ходе внедрения, когда вносились изменения в проектную документацию. И ещё одну закономерность я обнаружил - это удовлетворённость клиента в зависимости от срока ввода в эксплуатацию первого участка (этапа). Далее - это удовлетворённость услугами партнёра, удовлетворённость продуктом в целом. Здесь чётко видно, что если продукт внедряется в первые три месяца и есть хоть какой-то результат, то удовлетворённость на хорошем уровне - средняя оценка больше четырёх баллов. Если первый результат появляется позже трёх месяцев, задерживается, то удовлетворённость резко снижается. И это коррелирует с положением, когда идёт длительное проектирование, например, спроектировали только через полгода, но за это время уже изменяются бизнес-процессы: ещё вроде бы результата нет, а уже нужно менять, переделывать проектную документацию. И клиент явно выражает неудовлетворение: "За что я плачу? Вы проектировали-проектировали, ничего не работает, а теперь надо всё перепроектировать...". Заказчик недоволен, партнёр тоже, и это мешает дальнейшей работе. Если же система запускается этапами достаточно быстро, то результат есть, и он положительный. Вывод какой? Надо внедрять продукт более динамично.
Николай Комлев. Итог по обсуждённой теме "на бегу" подводить не хотелось бы. Я так понял, что тема, несмотря на то, что вроде бы и "старая", по-прежнему не теряет привлекательности, всё такая же актуальная. Тут высказывались разные взгляды, и есть о чём спорить. Мне показалось, это обсуждение прошло довольно интересно и тема получила новую окраску.
На мой взгляд, такого рода обсуждения весьма полезны для всех сторон, и, наверное, их стоит проводить чаще, возможно, не только через "круглые столы", и, может быть, не привязывать их к выставкам. Есть журнал "Бухгалтер и компьютер", и он открыт для подобных обсуждений и мероприятий...
Андрей Монахов. Не привязываться к выставкам достаточно сложно, однако если вы будете проявлять инициативу, говорить, что есть тема, которую мы хотим обсудить, завтра будет уже поздно, давайте быстрее... Мы можем и чаще собираться (предположим, в редакции) и проводить подобные мероприятия не обязательно на выставке. Будем считать, что основное мнение по многим вопросам все собравшиеся всё-таки успели высказать. По этой тематике присылайте свои более подробные соображения в редакцию. Ориентировочно, следующий "круглый стол" планируется в январе во время очередной выставки "Бухгалтерский учёт и аудит". Будем рады вас всех видеть.
Дорогие читатели! Редакция будет рада познакомиться с вашим опытом автоматизации и опубликовать на страницах журнала ваши мнения, наблюдения, позиции по данной теме и приведённым вопросам к ней.
