Автор статьи:SerBabah
Источник http://blog.hare.ru/blog/?id=19
Ну вот, нам представили уже почти окончательную версию V8. Презентация дала ответы на многие технические вопросы, но породила ряд других вопросов, уже концептуальных.
Речь уже не о самой платформе, а о модели разработки конфигураций под неё (в первую очередь – типовых и отраслевых). Останется ли модель прежней, как у V7, или будет изменена? Ведь сама платформа изменилась очень сильно.
Первая мысль такая: V8 будут продвигать и продавать не на уровне главного бухгалтера, а повыше. Главной мишенью, по логике вещей, станут топ-менеджеры, управленцы. Главный бухгалтер тоже может попасть в их число, но уже в контексте не фискального учёта, но финансового.
Также очевидно, что первые продажи V8 будут прямо лоббироваться IT-менеджерами тех компаний, где уже используется V7, используется на пределе и её возможностней не хватает. Ну, как это было с первыми продажами "клиент-серверной" версии 7.5.
Главный вопрос: потребности такого рынка. Какая система им нужна? Будут ли они пользоваться типовыми, какими именно и как именно. Имеет ли смысл разработка "комплексной" конфигурации под V8 и будет ли нужна такая конфигурация хоть кому-то?
Если пораскинуть мозгами, то вырисовывается следующая схема.
- Система состоит из модулей.
- Модули суть кирпичи, из которых собрано здание. Стыкуй, как хочешь.
- Не последнюю роль в разбиении системы на модули будет играть реальная финансовая структура предприятия.
- Собирая систему, нужно идти от целей, строить нужно не под какую-то абстрактную типовую методику, а под конкретную схему работы компании.
В чем премущество такой схемы? Обычно при сложном внедрении систему запускают в несколько этапов, заменяя блоками новой системы блоки старой. Физически невозможно запустить всё и сразу. Описанная технологическая схема идеально укладывается в концепуию "блочного" строительства информационного пространства предприятия.
Каждый модуль может быть обновлён отдельно от всех остальных. Потребность в обновлении у разных модулей разная (а также у разных модулей разная специфика, разные разработчики и т.д.)
Так же интересна идея организации обмена данными (УРБД или любой другой механизм обмена) в контексте отдельных модулей, а не системы в целом. Пример – распределённые склады (т.е. модуль оперативного учета) у одной компании плюс несколько юридических лиц в рамках одного предприятия.
Первым делом при внедрении мы проводим полное исследование бизнес-процессов компании (из тех сегментов, которые предназначены к автоматизации). Затем мы выбираем из репозитария типовых решений наиболее подходящие, стыкуем их и предлагаем заказчику в качестве решения.
Если грамотных типовых схем будет достаточно много, то можно разработать на их
основе энное количество вариантов стыковки, привязанных к реальным секторам рынка. Создание
"отраслевых решений" при такой модели разработки становится делом техники. Если в каком-то
конкретном случае типовой функциональный блок "не тянет", его можно "унаследовать" и
усилить. Почти что ООП..
Например, есть типовой модуль "Производство". Компания ничего не производит – не используем. Производит – тогда можно использовать типовой модуль от "1С" (потомок ПУБ), или типовой модуль от партнёра ("Рарус", "ИТРП", etc.). А вот есть ли смысл в каждой из этих конфигурации переписывать типовые же блоки "Снабжение", "Сбыт", уже реализованные в типовой "Торговле"? Если разобраться, то это ведь пустая трата ресурсов.
Блок "складского учета" логично в дальнейшем развить в подмножество модулей "Логистика". Нет складов у компании – не использем этот блок, есть – используем. Сложный склад (например, требуется пространственная модель) – берём типовую логистику и производим от неё потомка, усиленного нужными нам функциями.
Модули "Бухгалтерский учёт", "Налоговый учёт", "Кадровый учёт" имеют свою специфику, они сильно зависят от налоговой схемы и текущего законодательства. Количество юридических лиц на крупном предприятии может исчисляться десятками, у каждой будет своя специфика фискального учёта.
Что можно сделать? Да взять, и поставить в каждую из бухгалтерий типовое решение на V7, подстроенное под конкретную ситуацию. Возможностей V7 для этого вполне хватит. А из центальной информационной системы просто будем выбрасывать в эти базы первичку, и только ту, которая им нужна. Что с ней будет дальше – забота конкретного бухгалтера, ему за это деньги платят.
Один из возможных вариантов "типовой сборки" мог бы выглядеть так:
В общем и целом, вывод на рынок V8 (пока ещё не обвешанной многочисленными и практически несовместимыми друг с другом типовыми и отраслевыми решениями) даёт фирме "1С" уникальную возможность сделать огромный шаг вперёд и внедрить объектную модель построения типовых решений.
А партнёры получат возможность перейти от услуг "настройки" (которая обычно сводится к "тщательной обработке напильником") типовых решений к услугам управленческого и финансового консалтинга – реального, а не надуманного.
Предполагаемая бизнес-модель, или кто на чём зарабатывает. "1С": реализация платформы (коробки + лицензии);разработка и реализация типовых конфигураций-кирпичей; техническая и методическая поддержка (ИТС); обучение парнёров.
Партнёры: разработка отраслевых решений (на основе типовых блоков); консалтинг (обследование бизнес-процессов, разработка оптимальных вариантов автоматизации, etc.); реализация платформы и типовых решений; внедрение и сопровождение; обучение пользователей.
Модель-то, на самом деле, старая. Но переход к модульной архитектуре всего этого дела вносит в сущность модели изменения:
- Увеличение количества типовых блоков и заметное упрощение каждого блока в отдельности
- Перераспредение ролей: роль "сборщика" готового типого решения играют не методические отделы "1С", а консалтинговые отделы партнёров
- Разделение труда: консалтинг (сборка решения), разработка (реализация уникальных функций, недоступных в типовых решениях), внедрение (работа с персоналом заказчика). Монстры-многостаночники (на которых обычно и держатся проекты автоматизации) уходят в прошлое и замещаются цепочками специалистов, работающих по принципу "каждый на своём месте делает своё дело".
- Весь конвейер будет работать быстрее, как следствие, все участники зарабатывают больше.
Сами по себе новые технические возможности V8 не дадут никаких стратегических преимуществ. Преимущества можно получить, если концепция разработки и внедрения типовых решений будет переработана и позволит использовать новые возможности на всю катушку. Если же модель оставить прежней – с монструозными "комплексными", которые никто не может толком использовать, с интергацией отдельных типовых решений через не менее монуструозную "конвертацию данных", с десятками однотипных, но несовместимых партнёрских конфигураций, решающих одни и те же задачи десятком разных способов – то V8 логичнее будет назвать "1С:Предприятие 7.8", поскольку рывка не произойдёт. А ресурсы, вложенные в разработку V8, предполагают именно рывок.
Планов "1С" мы не знаем (мы их никогда не знаем). Но хочется верить, что новая платформа будет включать в себя не только новое программное обеспечение.
Начать дискуссию