Многие компании по мере роста бизнеса приходят к понимаю, что им требуется какая-то ERP-система. Если в малом бизнесе удается обойтись без этого инструмента, то средний бизнес с каждым днем активнее пользуется подобными средствами. Но чтобы выбрать ERP-систему, и даже для того, чтобы понимать, требуется ли в бизнесе этот продукт и какие преимущества принесет его использование, важно правильно понимать, что это такое.В своих статьях я часто занимаюсь описанием различных понятий. Как известно, чтобы продать какую-либо услугу, покупатель должен понимать, что это такое и почему ему эта услуга необходима. При этом очень важно договориться о терминах, только в этом случае результат будет соответствовать ожиданиям клиента. При этом термин ERP является одним из самых сложных и спорных.
Описание ERP системы
ERP – термин маркетинговый. Чтобы понять, о чем идет речь, а также изучить историю происхождения этого сокращения, можно обратиться к Википедии:
ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности[1][2]. ERP-система — конкретный программный пакет, реализующий стратегию ERP. Википедия
Это определение абсолютно верное, но относительно сложное для восприятия, особенно, если человек незнаком с такими понятиями, как «балансировка ресурсов» или «модель данных». При этом важно понимать, что термин ERP является, прежде всего, маркетинговым, и не имеет под собой какой-то глубокой методической базы. А потому я предлагаю такое определение:
ERP – это, прежде всего, информационная система, которая позволяет хранить и обрабатывать большинство критически важных для работы компании данных.
Что такое критически важные данные? И почему я говорю «большинство»? Дело в том, что некоторые ERP-системы имеют модуль «Производство», при этом он является отдельным программным продуктом, который не подключен по умолчанию к другим системам и блокам. Другие пытаются совмещать в себе все возможные процессы, необходимые для работы компании. Можно ли считать разные виды ERP полезными? Естественно, ниже я остановлюсь на этом вопросе подробнее. А сейчас вернемся к терминам.
- Критически важные данные – это перечень данных, без которых работа компании невозможна. Это и данные работы отдела продаж, и производство (если компания является производителем). Некоторые компании применяют ERP преимущественно для управления производством, так как для производства лучших решений не существует. Другие компании не являются производителями, например, дистрибьюторы, но также успешно применяют ERP. Для них критически важными становятся – дистрибьюция, управление персоналом, реализация товаров и услуг.
- Большинство данных: речь идет о перечне процессов и сведений, оптимальном для каждой конкретной компании. Конечно, идеально было бы собирать все данные и сведения обо всех процессах. Но это ведет к удорожанию внедрения. В результате руководство бизнеса вместе со специалистами по внедрению выбирают некое компромиссное решение, при котором в ERP системе собираются действительно необходимые для оперативного контроля и принятия управленческих решений сведения и процессы, а часть данных и процессов собираются в специализированных системах, к которым руководитель обращается по мере необходимости.
Перечень критически важных данных и та их часть, которую обязательно нужно обрабатывать в ERP системе, вычисляются эмпирически для каждого конкретного бизнеса. Именно анализ этих данных и правильное их определение дает ответы на вопросы: есть ли необходимость в покупке и внедрении ERP системы, и оправдаются ли затраты на этот вид автоматизации бизнеса.
Из чего состоит ERP система
Все ERM-системы, независимо от того, кто их разработчик, объединяет общая архитектура, которую можно описать следующим образом:
- Платформа. Базовые возможности и среда для работы модулей и компонентов. В код платформы изменения может вносить только разработчик. Пользователи и специалисты по внедрению не имеют доступа к этому программному коду. В состав платформы входят:
1. Ядро. Программная среда, в которой будет производиться работа, для которой можно писать какие-то надстройки и компоненты.
2. Базовый функционал. Перечень справочников и функций, без которых не может работать ни одна компания. Это справочник пользователей с правами доступа, справочник клиентов, справочник товаров/услуг и т.д. Этот функционал встроен в платформу, в отличие от модулей он не может отключаться.
- Управление данными. База данных, в том числе, хранение и методы обработки (интерпретации) данных. В эту категорию входят хранилище данных на сервере, программное обеспечение для работы с базами данных (SQL или любая альтернатива), инструменты для интерпретации и обработки данных и отправки их в программные модули.
- Модули. Компоненты, которые подключаются к платформе по мере необходимости. Все они работают с единой базой данных и применяют базовый функционал (по мере необходимости). В остальном модули работают независимо друг от друга, могут «бесшовно» подключаться и без проблем отключаться, если потребность в них исчезла. Такая модульная структура – важная отличительная черта ERP-систем. Модули делятся, в свою очередь, на несколько типов:
1. Модули внутреннего использования. Этот уровень – подключаемые модули, которые используются сотрудниками компании. Это управление складом, производство, бухгалтерия, CRM и пр. Модули можно подключать, отключать, настраивать силами специалистов по внедрению. В стандартный набор обычно входят — MRP, HR, CRM, Упарвление снабжением и закупками.
2. Модули работы с внешними пользователями. Этот слой содержит в себе модули, необходимые для взаимодействия с внешними пользователями, потенциальными и реальными клиентами компании, партнерами, пользователями продукции, поставщиками и покупателями. Это может быть интернет-магазин, личные кабинеты для поставщиков и покупателей на корпоративном сайте и тому подобные решения. Некоторые ERP-системы содержат в себе готовые CMS-системы для создания интернет-магазина или корпоративного сайта с нуля, другие предлагают только отдельные инструменты «надстройки» к сайту и/или клиентские приложения (для мобильных и планшетов).
3. Коннекторы — готовые решения для связи со сторонними приложениями. Чаще всего используют API из ядра платформы. Позволяют интегрировать телефонию, настроить обмен данными с сайтом или любыми программными продуктами и системами. Коннекторы предназначены только для обмена данными и обычно используются для обмена данными с EDI,
CMS, CAD, BI, OLAP и др. То есть с теми системами которые не входят в EPR, но используются в компании.
Описанная выше структура характерна для ERP с логической точки зрения. У некоторых систем нет ярко выраженной модульности, они все уже встроены в программу, но использовать их можно отдельно друг от друга по мере необходимости. Другие называют отключаемые модули подсистемами. А часть ERP-систем выделяют все модули действительно в отдельные продукты. И предлагают купить ядро, а к нему – перечень модулей на выбор. С возможностью в будущем покупать и добавлять возможности по мере необходимости.
Преимущества модульной структуры ERP
Важным преимуществом ERP систем является возможность подключать и применять любой из модулей (внутренний или внешний) в сжатые сроки. Причем, возможности, которые таким образом подключаются к ERP, добавляются в систему абсолютно «бесшовно». В этом заключается важное отличие ERP от интеграции нескольких программных продуктов между собой или от системы, которая выросла из специализированной за счет многочисленных доработок и надстроек силами собственных или приглашенных IT-специалистов.
- Каждый из модулей ERP-системы работает независимо от других, он может быть подключен или отключен в любой момент времени, может просто не использоваться, при этом другие модули смогут продолжать работу. А для подключения того или иного модуля нет необходимости вносить изменения в программный код ядра, других модулей.
- При использовании ERP системы для расширения возможностей и подключения нового подразделения нет необходимости дописывать программный код, создавать новую часть программы с нуля или заниматься сложной и, порой, не очень удобной интеграцией разных программ. Достаточно просто выбрать нужный модуль, подключить и настроить его под нужды бизнеса. В ERP системах практически все, что может потребоваться при автоматизации бизнеса, уже реализовано. Самописные доработки требуются в единичных случаях.
Например, можно применять CRM-модуль, но отказаться от модуля управления персоналом. По мере роста и развития компании любой из модулей без особых сложностей подключается, настраивается и программный продукт продолжает работу уже с новыми функциями.
Нередко я слышу от клиентов фразу «мы разработали свою ERP-систему». На самом деле в этом случае применяется не ERP, а некое подобие, разросшееся из какой-то специализированной системы. Например, начали работать в CRM, потом дописали к ней модуль для работы склада, настроили обмен данными с бухгалтерскими программами и т.д. Или начали с учетной системы и сайта, и также – проводили интеграцию, дописывали модули, все это каким-то образом «стыковали» друг с другом.
Все это не является ERP системой. Основное отличие ERP от любых подобных программ заключается в том, что ERP изначально создается в виде конструктора из платформы и модулей, которые можно подключать по мере необходимости. Здесь уже предусмотрены самые разные возможности.
ERP – это продукт, который изначально создан, с одной стороны, для масштабируемости, а с другой – для обеспечения максимума возможностей.
В ERP системе очень четко разделены границы модулей. И отключение любого из них (кроме некоторых базовых справочников и возможностей) никак не повлияет на работу оставшихся. В самописных системах, которые разрастаются из специализированных, как правило подобная архитектура не предусмотрена. И если вы отключите возможности, например, бухгалтерии, скорей всего, программа перестанет работать или будет работать не корректно. Потребуется вмешательство программиста и значительные доработки. Подобные программные продукты, как правило, используют общие документы и компоненты в них тесно переплетены между собой. Архитектура ERP – по-настоящему модульная. И это очень важно понимать.
Т.е. если вы выбираете ERP-систему, вы получаете единую систему для автоматизации различных подразделений вашей компании плюс широкий перечень возможностей для развития. Вам очень долго не потребуется менять программный продукт, достаточно будет вызвать специалистов, которые помогут подобрать и подключить готовые модульные решения. А их существует огромное количество для самых разных сфер бизнеса и особенностей работы.
Для чего используется ERP система?
Внедрение любой ERP-системы позволяет получить определенные преимущества и особенности. О том, кому и зачем необходимо внедрение ERP, давайте разберемся подробнее.
Принцип единой базы данных: контроль, управление, точность и оперативность
Для понимания этого принципа давайте представим компанию до и после внедрения ERP. Допустим, организация имеет собственное производство. Вероятнее всего, учет на производстве ведется в таблицах Excel либо в специализированной программе. Складской учет работает в собственной учетной системе, бухгалтерия – в бухгалтерском программном обеспечении. Передача данных от подразделения к подразделению производится в виде бумажных документов, а иногда даже в устной форме, после чего вручную вносится в нужную систему учета.
Такой подход очень сильно зависит от человеческого фактора, в итоге, сведения поступают с задержками, часто – значительными. Нередки искажения и ошибки, а в некоторых случаях какие-то данные вообще не поступают в систему по причине человеческого фактора, что приводит к сбоям в работе, необходимости в регулярных сверках и т.д. Более того, любая ошибка и последующее исправление может привести к значительным убыткам. Например, ошибка в коде или размерах при передаче данных из проектировочного отдела на производство оканчивается очень печально, так как производится в итоге совсем не то, что было заказано и спроектировано. Возникают простои, списания брака или избыток товаров на складе, срыв сроков по договору с клиентом и т.д.
В случае внедрения ERP системы создается единая база данных, в которую собирается вся информация, используемая разными подразделениями. В этом случае процент ошибок значительно снижается, так как данные вносятся в систему один раз специалистом, после чего считываются автоматически всеми подразделениями в необходимом для работы формате и кодировке.
Кроме того, скорость передачи данных при применении единой базы становится мгновенной. Т.е. сразу после того, как проектировщики или специалисты по продажам внесли в базу заказ, его видят в проектном отделе или на производстве. Также и отметка об оплате появляется на заказе сразу после того, как бухгалтерия получила сведения из банка. Снижается число ошибок, связанных с человеческим фактором, а те, которые все же возникают, устраняются значительно быстрее.
А потому ERP система необходима компаниям, для которых скорость и точность передачи данных между подразделениями является критическим фактором.
Гибкость в работе компании с учетом изменений рынка
Если компания нацелена на максимальное соответствие постоянно меняющимся условиям рынка и потребностям клиентов, ей просто необходимо оперативный обмен данными между подразделениями и оперативность принятия управленческих решений.
Небольшая компания в случае поступления нетипичных заказов или изменения объемов закупки тех или иных товаров, конечно, может обойтись и без ERP-системы. Когда все сотрудники работают в одном небольшом офисе, всегда можно скоординировать действия между собой, а заказ сформировать на основе данных из заказов даже в Excel-таблицах.
В условиях среднего бизнеса, где имеются несколько подразделений, филиалов, возможно, свое производство, единая база данных и оперативный обмен данными в условиях меняющихся потребностей покупателей становятся критичны. Важно, чтобы вся информация собиралась в сжатые сроки, производились своевременные закупки, а также вносились оперативные изменения в план производства и поставок. Здесь без единой системы с общей базой данных не обойтись.
Сложные бизнес-процессы: интеграция уже не помогает
Еще один случай, когда без ERP-системы не обойтись, это компании, в которых по мере роста и развития появляются сложные процессы, требующие значительных объемов обмена данными. На определенном этапе интеграция между несколькими программными системами становится сложной, громоздкой и нерентабельной. ERP система становится решением этой проблемы.
Что получает бизнес от внедрения ERP
ERP — это, прежде всего, возможность объединить все бизнес-процессы в одной мощной и удобной системе, а потому преимущества решения можно перечислять долго. Ниже я выделил только некоторые, которые я считаю наиболее значимыми:
- Доступность данных. Один раз внесенные данные становятся доступны в рамках целой системы, при этом не требуются сверки, дополнительные согласования и проверки.
- Согласованность данных. Применение общей базы данных позволяет избежать этапов сверки и согласования данных. Например, если отдел проектирования внес и утвердил какой-то проект, данные из этого проекта отдел закупок может использовать для работы сразу, без дополнительного этапа подтверждения.
- Контроль работы сотрудников. В случае, когда одно из подразделений вносит данные, например, о расходе (перемещении) товара, то другое подразделение сразу же получает об этом сведения, и после реального получения перечисленных позиций ставит его себе на приход. Расхождение в цифрах в этом случае практически невозможно, общая база данных исключает вероятность многих злоупотреблений, а руководитель в режиме реального времени может выявить любые расхождения и их причины.
- Значительное снижение числа ошибок, связанных с человеческим фактором. Единая система не позволит списать товар не с того склада, так как общая база данных укажет, что товара там нет. Информация об оплатах будет передаваться в бухгалтерию и отдел продаж автоматически на основе данных из банка или кассового аппарата, что также исключает ошибки. Технические параметры и данные проекта также будут переданы автоматически, без искажений и т.д.
- Готовый набор объединенных между собой инструментов. Например, если отдел продаж создает счет-фактуру, то она является основанием для автоматического создания бухгалтерских документов, а после оплаты – расходных документов со склада.
Значительное количество инструментов, которые могут понадобиться в будущем. Практически все ERP-системы очень мощные и универсальные. В них имеются возможности для реализации огромного количества процессов. Практически всегда при внедрении используется только часть этих возможностей. А по мере роста и развития компании подключаются или докупаются модули, позволяющие внедрять новые решения, подключать к работе новые подразделения компании. И все это – с минимальными затратами финансов и времени.
Что важно знать при выборе ERP системы
Один из первых вопросов, которые возникают при выборе любого программного обеспечения – это выбор между Saas или Stand-Alone, т.е. оплачивать доступ к системе, расположенной в «облаках» или покупать «коробочное решение». Подробно об этом выборе я рассказывал в статье Что такое CRM-системы и как их правильно выбирать?
В случае ERP-систем существует точно такой же выбор, как и при внедрении CRM-систем. Вы также можете обратить внимание на SAAS-решения или купить и внедрить “коробку”. Но есть один нюанс, который очень важно учитывать. Дело в том, что ERP — система сама по себе крупная, включающая большое число возможностей. Фактически, в ней объединяются все данные о работе компании. И в случае применения “облака” будет крайне сложно сменить сервис, если в этом возникнет необходимость. В отличие от CRM-систем, которые очень популярны как раз в варианте SAAS, массив данных в ERP объемен и громоздок, и в случае перехода с одного программного продукта на другой, возникает вопрос, что с ними делать.
А потому имеет смысл ориентироваться на покупку программного продукта «в коробке» и последующую его установку на собственных или арендованных серверах. Итак, на что нужно в первую очередь обращать внимание:
- Выбор команды или специалиста по внедрению. Если некоторые программные продукты, например, CRM-системы для небольшой компании, при большом желании реально внедрить даже без специалиста или с его минимальным участием, то ERP-система без опытного специалиста останется очередной «невостребованной коробкой». Сложность программных продуктов этого семейства обусловлена сложностью задач, которые перед ними ставятся. Единая база данных, интеграция с другими программами, многие другие нюансы работы невозможно настроить без участия профессионала.
- ERP система это не ключ от всех дверей и не швейцарский нож. Так же как и остальные системы они могут иметь специфику, и отраслевую принадлежность. То есть если у вы занимаетесь продажей, а не производством, то ERP вам следует брать прежде всего для продаж. Тоже самое касается модулей.
- Понимание бизнес-процессов. Очень важно, чтобы специалист по внедрению глубоко понимал не только особенности программного продукта, но также имел достаточно широкий перечень знаний в сфере бизнеса, так как для настройки работы бухгалтерии необходимо понимание того, как и с чем работает бухгалтер. Для внедрения ERP на складе нужны знания складского учета. А потому здесь особенно важен уровень знаний и понимание бизнес-процессов компании руководителем проекта, который будет ставить перед техническими специалистами задачи и контролировать их исполнение.
- Бюджет. ERP-система как программный продукт стоит сравнительно дорого, независимо от разработчика. А ведь для успешного внедрения потребуется сотрудничество с опытными специалистами. И если бюджета хватает только на оплату программы, то в результате «коробка» оказывается невостребованной, т.е. компания впустую тратит значительную сумму. Рассчитывайте свои возможности заранее.
Недостатки ERP-систем
Недостатки этого типа программных продуктов являются следствием их преимуществ. Единая база данных и единая система порождают значительное количество связей, высокую сложность самой системы и высокие требования к аппаратной (серверной) части. А потому для организации работы ERP-системы необходимо мощное оборудование, что влечет за собой соответствующие затраты.
Еще одна проблема, которая очень часто возникает при внедрении ERP системы, это обеспечение безопасности данных. Так как в системе работают все подразделения и сотрудники компании, то и права доступа необходимо настроить для каждого свои. И если при использовании отдельных специализированных программ обычно требуется создать несколько уровней доступа (рядовой сотрудник, начальник подразделения, руководитель), то система прав доступа в ERP получается сложной. Здесь нужно настроить и доступ к модулям для разных подразделений, и внутри каждого отдела настроить иерархию. Столь сложная настройка часто приводит к ошибкам и требует дополнительного времени на тестирование и отладку.
Кроме того, применение единой системы с единой базой данных при всех своих преимуществах также содержит в себе определенную проблему. Если по той или иной причине перестает работать ERP-система (отключается электричество или возникают другие проблемы на сервере), останавливается работа всей компании. А потому необходимо особо внимательно отнестись к обеспечению надежности работы серверной части и своевременному техническому обслуживанию.
Также ERP-системе присущи недостатки, которые характерны для всех сложных систем, а именно — высокий уровень вхождения и, соответственно, высокий уровень затрат на внедрение.
Резюме
В этой статье я постарался максимально просто и без лишних технических подробностей рассказать о том, что такое ERP-системы и какую пользу они могут принести бизнесу. Я надеюсь, что сумел дать базовые знания о том, зачем может быть нужна такая система, в каких случаях она нужна, а где затраты на ее внедрение, скорей всего, не окупятся. А понимание того, что могут ERP системы, а также, что вы хотите получить от их внедрения, поможет сделать правильный выбор среди программных продуктов этого класса.
Комментарии (55)
YaMishar
14.07.2017 16:54Хорошая статья. Однако, как сотрудник разработчика SaaS ERP системы позволю не согласиться с выводами о недостатках SaaS. Собственно что находится в этом облаке — БД (MS SQL) и сама ERP (обычный сайт IIS).
Что мешает переносить потом это всё к себе на мощности? Наши клиенты постоянно это делают в обе стороны, никакой проблемы в этом нет.
JustRamil
14.07.2017 17:34Вы меня неправильно поняли, я не писал о том переезде из облака к себе. Я написал о смене сервиса. То есть если вы решили попробовать сервис «X», и он (сервис «X») вам не понравился, вам то в связи со спецификой системы вам очень сложно будет перейти на сервис «Y».
Выдержка из статьи:
В случае ERP-систем существует точно такой же выбор, как и при внедрении CRM-систем. Вы также можете обратить внимание на SAAS-решения или купить и внедрить “коробку”. Но есть один нюанс, который очень важно учитывать. Дело в том, что ERP — система сама по себе крупная, включающая большое число возможностей. Фактически, в ней объединяются все данные о работе компании. И в случае применения “облака” будет крайне сложно сменить сервис, если в этом возникнет необходимость. В отличие от CRM-систем, которые очень популярны как раз в варианте SAAS, массив данных в ERP объемен и громоздок, и в случае перехода с одного программного продукта на другой, возникает вопрос, что с ними делать.
YaMishar
14.07.2017 17:42Хорошо. Я прицепился к этому «или» в «SAAS-решения или купить и внедрить коробку». Ну тогда действительно согласен — любой переход довольно болезненен. Впрочем, иногда совершается много раз, особенно в процессе роста компании.
Скажем путь Excel->QB->Netsuite->Axapta->Oracle вполен возможен.
помню пример, когда в течение 3х лет одна компания российская провела 3 внедрения разных уровня успешности. Первое внедрение показало и настроело бизнепроцессы, второе внедрение — побесились от жиру (но тоже успешное), третье внедрение — в результате поглощения. И ничего, сотрудники не взвыли.
Pusk1
14.07.2017 17:2119 лет этими системами занимаюсь, но не видел ни одного решения без доработок под клиента. Мало того, после запуска требуются поддержка и развитие.
Основные тезисы:
1. Локальное законодательство часто поддерживается с недопустимыми ограничениями,
2. Уникальные, дающие преимущество процессы приходится реализовывать отдельно.
3. Приложения и решения архаичны. Например, значительная часть технологического стека корнями из начала 90-х, и существующие решения содержат гигантское количество атавизмов и ограничений. Про Oracle Forms слышали? 95% интерфейсов Oracle EBS до сих пор на нём. И SAP FI не лучше.
4. EPR для любой компании является аналогом религии. Даже переход на новую версию раз в 5-10 лет обычно проходит очень болезненно. Смена вендора — крайне редкий случай.
5. Не верьте про независимость приложений. Часто их делали или покупали отдельно, а потом интегрировали с существующим функционалом. Теперь представьте стоимость поддержки. Кроме того, в любой ERP есть общие справочники. Например, номенклатурный. Банальную ошибку ввода придется исправлять в нескольких приложениях.
6. Самодельных не бывает. Выбор поставщиков в России небольшой. SAP или Oracle + 1С для локальных компаний.Dmitry_5
15.07.2017 15:54Про САП слышал от его пользователей, что там кнопка в интерфейсе может быть реализована просто как пустое место на форме. Ничего нет, а нажимать надо в это место окошка. Это отлично характеризует сап
DrPass
16.07.2017 01:431. Локальное законодательство часто поддерживается с недопустимыми ограничениями,
Могу добавить, что для многих клиентов крайне неожиданным оказывается открытие, что им будет выгоднее и надежнее купить дополнительно к их ERP обычную 1С, интегрировать их, и использовать ERP для управленческого учета, а 1С для бухгалтерского и фискальной отчетности.
BDG
18.07.2017 22:37Поддержу по тезисам. Практика жизни несколько отличается от теории, описанной в статье, хотя она дает общее представление о проблемах вокруг ERP. Сегодня в России есть два основных лагеря клиентов — корпоративный рынок с SAP (очень редко встречается Oracle EBS) и малый бизнес с 1с. Все отличное от этого постепенно заменяются на эти варианты. Галактика или Парус — да хорошие системы, но их ждет та же участь быть съеденными этим процессом и я вижу как сейчас ИТ-директора этих компаний смотрят на 1с. На практике выбор системы ERP несколько иной и последовательность отбора отличается от теоретической (хотя оно очень правильное). Первое что спрашивает клиент — кто это будет поддерживать, — «где ваши разработчики и как быстро они приедут ко мне на предприятие?». Быть может для малого и микробизнеса и приемлем OnlineERP, но крупняк покупает исключительно OnPremise, т.е. на локальных серверах (ну или арендуемых, но опять же в их собственности). Следующий вопрос — интеграция, иначе говоря как предлагаемая ERP-система будет обмениваться данными с другими системами, в первую очередь PLM/PDM системы и 1с бухгалтерия. Далее идет референсы, — те клиенты, которые используют у себя эту ERP-систему и бесконечно довольны ей настолько, что могут об этом говорить новым клиентам. Ну и завершающий вопрос — это цена, если конечно же разработчик ERP-системы доберется до этого пункта. Сейчас рынок испытывает проблемы с заказами снижения объемов производства и им нужна гарантированная система и рисковать при этом никто не хочет. Покупать неизвестность, если только эта неизвестность застрахована возвратом инвестиций от неудачного внедрения или 100% ответственностью разработчика-внедренца решать все, в т.ч. мелкие проблемы тем самым помогая заказчику стать эффективным предприятием. Да и не забывайте о таком риске, — как требование переноса системы на «другое» решение, в случае если вы не смогли реализовать проект для вашего заказчика. Это означает что разработчик ERP-системы или партнер-внедренец должен иметь два статуса, один из которых 1с-партнер по ERP 2.0.
burnitblue
14.07.2017 17:22Есть ли будущее у Oracle ERP? :)
BDG
18.07.2017 22:42Да есть, — это хорошее решение. Но его рынок в России незначительный, на уровне погрешности, потеря которого будет совсем незаметна в случае чего.
burnitblue
19.07.2017 14:52Интересно, а Вы согласились бы с мыслью о том, что в России Oracle eBS не подходит?
В те времена когда я занималась внедрением, мы кастомизировали Оракл чуть менее чем полностью. Получился свой Оракл с блекджеком…BDG
19.07.2017 15:11Кастомизация Oracle EBS — это обычная мировая практика, поскольку не бывает двух одинаковых крупных предприятий и каждое имеет большой объем задач по автоматизации процессов, что собственно требует внедрения. При этом крупный проект не обходится без консалтинга (Oracle consulting имеет хорошую практики в России реализации таких проектов) или системных интеграторов а-ля Борлас или Ланит. Сравнивать OEBS c SAP R3 не имеет смысла — они отличаются не критично, вопрос лишь в практике, best practice, которые описаны как готовые отраслевые решения. Обратная сторона медали — это жесткость применения этих best practice, когда происходит их навязывание руководителям предприятий, создающих шаблонность реализации задач что хорошо для разработчика, но не очень для предприятия. С большой вероятностью это послужило причиной почему SAP имеет в России большее число инсталляций, — он более шаблонен. Оракл позволяет создавать более сложные системы, но это под них нужен ТАКОЙ ЗАКАЗЧИК. Посмотрите где внедрен SAP и где используется Oracle eBS, — это как правил нефтянка где нет большого кол-ва переделов и производство достаточно простое, нужно лишь делать хорошую отчетность для инвесторов. У Oracle есть продукт Oracle JDE он позиционируется как конкурент SAP Business One, но он так и «взлетел» в России хотя функционал задач очень похож, но по иному сделан маркетинг и те же пресловутые best practice слабее. Если уж коснулись маркетинга, то SAP работает в т.ч. и на Oracle DB, сильно надавить на SAP Ораклу не удается, мешает эта зависимость.
Pusk1
19.07.2017 17:12Это аналог американского 1С. 19% мирового рынка и неплохая гибкость (в сравнении с SAP). GE, Macdonalds, Boing и прочие глобальные компании с американскими корнями хорошо и регулярно оплачивают его развитие. В России ему светит только переход на новые версии и роллаут на локальные дочки в глобальных компаниях.
Drac013
19.07.2017 17:19Таки, аналог нашего 1С в США — это продукты Intuit: QuickBooks Enterprise, QuickBooks Online. Они в первую очередь ориентированы на малый и средний бизнес. Хотя 1С уже активно и вполне удачно зашло на рынок Enterprise решений в России.
Areso
23.07.2017 08:47ИМХО, у 1С проблемы с масштабированием и тем, что везде торчат уши бухгалтерии (а также бух/налоговых проводок и регламентированных отчетов).
Drac013
24.07.2017 10:14Что вы в данном случае понимаете под «масштабированием»?
Ну, и, говоря о ЕРП системах, пенять, что там везде лезет бухучет, откровенно странно. Бухучет — это обязательная часть финансового учета любого предприятия (кроме определенного списком исключений) во всех странах мира.
А если хотите 1С без проводок и бухгалтерии, то есть решения для Документооборота, CRM, ITIL и другие.Areso
24.07.2017 10:231) системы управления релизами, обновлениями, разработкой, тестированием, исправлением и так далее. Работать на предприятии, где окно для обновления шириной 1 час только ночью и то приходится вручную выгонять всех пользователей — неудобно. При этом у нас не очень много пользователей. Как обновлять системы, где технологических окон просто нет?
2) существует управленческий учет, или как вариант — забалансовый учет в терминах бухгалтерии. Причем управленческий учет может быть никак не связан с бухгалтерией. Потому что обновлять (для поддержания актуальности с т.з. законодательства) и поддерживать монструозную конфигурацию с большим количеством доработок крайне неудобно. Оттого, что где-то там что-то придумали в думе или в минфине/цб, станки и их загрузка никак не меняется. Конвейер. Весы. Вот это все. Это привязывается к бизнес-процессам, в первую очередь.
3) да, они существуют.DrPass
24.07.2017 11:08Причем управленческий учет может быть никак не связан с бухгалтерией
Управленческий и бухгалтерский учет с архитектурной точки зрения в ERP — это ведь одно и то же. Всего лишь разные аналитики для одних и тех же хозяйственных операций. А навороченная система бухгалтерских проводок — это всего лишь бизнес-требование для работы в отечественной среде. Если вы ведете бизнес в exСНГ, вы никуда от неё не денетесь, и вам нужно будет её вести в своей ERP, ну или использовать стороннюю систему для бухгалтерского и налогового учета, и заморачиваться с интеграцией.Drac013
24.07.2017 11:42А навороченная система бухгалтерских проводок — это всего лишь бизнес-требование для работы в отечественной среде. Если вы ведете бизнес в exСНГ, вы никуда от неё не денетесь
Вы никуда не денетесь от нее нигде в цивилизованном мире. Только там будет не РСБУ, а МСФО или GAAP.DrPass
24.07.2017 12:12Вы никуда не денетесь от нее нигде в цивилизованном мире.
В цивилизованном мире как раз в большинстве случаев денусь. Если не брать в расчет крупный бизнес с его кучей отчетности, то нередко в организациях нет никакого GAAP, и вообще даже бухгалтерии как подразделения. Мелкий и средний бизнес в Европе/США и прочих Израилях бухгалтерский учет и налоговую отчетность охотно и успешно отдают на аутсорс.Drac013
24.07.2017 12:53Мелкий и средний бизнес в Европе/США и прочих Израилях бухгалтерский учет и налоговую отчетность охотно и успешно отдают на аутсорс.
В России вы тоже можете отдать бухгалтерию на аутсорс. В чем разница-то? Того факта, что ваша организация должна вести корректный бухгалтерский учет, это никак не отменяет. Как вы это будете делать — ваши проблемы.DrPass
24.07.2017 13:20В чем разница-то? Того факта, что ваша организация должна вести корректный бухгалтерский учет, это никак не отменяет.
Хех, разница колоссальная. Вы себе хорошо представляете разницу между бухгалтерским учетом, например ООП и ИП (если взять в пример Россию)? Вот, к примеру, продаём фуфырик со склада за наличку. В бухучете мы сделаем проводку по списанию себестоимости товара, с субконто по фуфырикам, вторую по начислению дохода от реализации товара, третью — взаиморасчетами с клиентами, с субконто по конечному покупателю, на увеличение дебиторки, четвертую по приходу по кассе, пятую — по взаиморасчетам с клиентам на уменьшение дебиторки.
В случае ИП мы просто отмечаем, что получили такую-то сумму по доходам. И в конце периода мы за неё платим налог.
И то, и другое — бухгалтерский учёт. Но сложность и ресурсоемкость у них несопоставимая. Второе легко отдать на аутсорс, первое — проблематично.
Так вот, некрупные предприятия в Европе ведут учёт намного ближе ко второму варианту. У них нет необходимости вести сложный план счетов и отражать всю аналитику там. Есть достаточно нехитрые формы налоговой отчетности, и им просто нужно иметь корректные цифры для этих форм.Drac013
24.07.2017 13:43Хех, разница колоссальная. Вы себе хорошо представляете разницу между бухгалтерским учетом, например ООП и ИП (если взять в пример Россию)?
Я себе эту разницу прекрасно понимаю, так как занимался разработкой и сопровождением бухгалтерских систем сначала в России, а сейчас разрабатываю SaaS бухгалтерскую систему для малого бизнеса и CPA в США. Коллега, сидящий рядом, занимался тем же в Германии.
То, что вы описали в случаи ИП — это не бухучет. ИП на УСН как раз-таки освобождены от ведения бухучета.
В бухучете мы сделаем проводку по списанию себестоимости товара, с субконто по фуфырикам, вторую по начислению дохода от реализации товара, третью — взаиморасчетами с клиентами, с субконто по конечному покупателю, на увеличение дебиторки, четвертую по приходу по кассе, пятую — по взаиморасчетам с клиентам на уменьшение дебиторки.
Все эти проводки будут сформированы и при проведение Sales Invoice, Purchase Invoice в США и в Германии. Откройте Xero или QuickBooks Online, ориентированные на малый бизнес (демо доступ бесплатно и быстро можно сделать, за пару минут) и увидите, что каждый документ, отражающий хозяйственную операцию, генерирует достаточно много проводок. Там будут и счета и для себестоимости (Cost of Goods Sold), и учета номенклатуры (Inventory), и взаиморасчетов (Accounts Payable/Receivable).
Между планами счетов есть значительная разница: в РСБУ он фиксированный, а в GAAP и MSFO — нет. Т.е. компания может разработать свой план счетов для учета. Но большинство малых компаний, конечно же, использует что-то вроде дефолтного плана счетов.
И между США и Россией есть еще один нюанс: у нас бухгалтера ведут и бухгалтерский и налоговый учет, а в США CPA (Certified Public Accountant) предпочитают не лезть в налоговый учет, ибо он слишком сложен и рискован и требует больших компетенций в юридической области.
Так что ваше представление о разнице между бухгалтерским учетом здесь и там несколько не соответствует действительности.DrPass
24.07.2017 13:56Так что ваше представление о разнице между бухгалтерским учетом здесь и там несколько не соответствует действительности.
Хм. Похоже, вы вообще не поняли, о чем была речь :) Речь была не о разнице между бухгалтерским учетом, а о его востребованности здесь и там. Здесь вы не можете вести бизнес без бухгалтерского учета. Там — можете. И большинство там так и поступает. То, что QuickBooks имеет план счетов и ведет проводки, я вроде бы нигде и не оспаривал. Но вот сравните, например, охват рынка здесь у 1С, и у QuickBooks и его аналогов там.
Drac013
24.07.2017 11:401) системы управления релизами, обновлениями, разработкой, тестированием, исправлением и так далее.
Хм, это несколько не похоже на то, что имеют ввиду под термином масштабирование. Обычно имеют ввиду либо горизонтальный рост системы (количество пользователей, объем данных, количество транзакций), либо вертикальный (от киоска с одной кассой и продажей за наличные, до корпорации с сотнями разных бизнес-процессов). Но, допустим. У 1С есть на данный момент свой инструмент СППР для названных вами целей. После финального релиза 1C:Enterprise development tool, можно будет пользлваться более привычными и распространенными инструментами.
Работать на предприятии, где окно для обновления шириной 1 час только ночью и то приходится вручную выгонять всех пользователей — неудобно. При этом у нас не очень много пользователей. Как обновлять системы, где технологических окон просто нет?
А у вас есть примеры того, как с этим справляются другие популярные вендоры ERP-систем: SAP, Oracle, Microsoft? Когда я несколько лет назад изучал этот вопрос, то у них тоже не было решений этой проблемы.
2) существует управленческий учет, или как вариант — забалансовый учет в терминах бухгалтерии.
Управленческий учет не имеет никакого отношения к забалансовым счетам бухгалтерии. В том числе в терминах бухгалтерии. Забалансовый счет не перестает быть бухгалтерским, просто он служит для учета информации, которая, сюрприз, не включается в бухгалтерский баланс, а потому для них не применяется требование корректной двоичной записи (например, товары принятые на реализацию).
Причем управленческий учет может быть никак не связан с бухгалтерией.
Не может. Любая хозяйственная операция должна иметь отражение в бухгалтерском учете, не важно, какая система учета используется: МСФО, РСБУ, GAAP. Другое дело, что в управленческом учете есть операции помимо хозяйственных: бюджетирование, казначейство и прочие.
Потому что обновлять (для поддержания актуальности с т.з. законодательства) и поддерживать монструозную конфигурацию с большим количеством доработок крайне неудобно.
А для этого придумали простой подход: бухгалтерия отдельно, остальное отдельно. Еще зарплату выделяют в отдельную систему часто.
станки и их загрузка никак не меняется. Конвейер. Весы. Вот это все.
Все это не относится к управленческому учету :) Это именно что управление оборудованием. Чаще всего, ERP система получает результат от ПО, которое им управляет. Планирование производства, да (MRP или KANBAN и сопутствующие им системы), но до уровня конкретного оборудования они редко опускаются.
maslyaev
14.07.2017 17:47+1Про модульность. Здесь нужно понимать, что конкретно из того, что говорится, является реальностью, а что условностью или маркетинговым мифом. В своей основе любая ERP-система — огромный и чрезвычайно тяжеловесный монолит, переплетённый множеством внутренних взаимозависимостей. Даже если клиент купил всего лишь один маленький модуль и ему доступно всего несколько простых формочек, из этого вовсе не следует, что под капотом у него тоже всё просто и прямолинейно. Вовсе нет, под капотом всё равно сидит полный объём монструозности,. Просто она выключена. Скрыта. Реальная модульность — несбыточная мечта, и много отважных полегло в погоне за ней. Условная модульность — тоже неплохая штука и, например, с задачей продажи продукта/услуг по частям неплохо справляется. И пользовательский интерфейс разгружает. Но нужно понимать степень условности этой условности.
Конечно, понятие «встраиваемый модуль» в мире ERP существует, но рассчитывать на то, что можно будет из достаточно широкого ассортимента выбрать модуль финансов, склад, планирование производства, HR, и ещё кучу всего понабирать в корзинку, прогуливаясь вдоль стеллажей — в высшей степени наивно. Ткнув пальчиком в конкретный понравившийся встраиваемый модуль, мы сразу получаем список того, что ещё в системе должно быть. Притом не в стиле «HR и бюджетирование», а конкретный HR и конкретное бюджетирование. Можно, конечно, взяв в руки напильник, адаптировать модуль под другое окружение, но это время, деньги и риски. Плюс потеря возможности лёгкого обновления на новые версии.
Принцип единой базы данных
Единая база данных — хорошая штука, но бывает, что жизнь подбрасывает сюрпризы. Например, внедрили ERP в многопрофильном холдинге, а потом прошёл год, и одну из дочек взяли и продали. По-хорошему она должна уйти со своими историческими данными, но как их безболезненно вычленить в отдельную базу, чтобы ничего не сломалось?
Кроме того, единая база данных — это вариант реализации принципа «все яйца в одной корзине». Заказчики ERP-систем склонны проявлять фантастическую самонадеянность, а поставщики решений не спешат эти иллюзии развеивать.
Бюджет
Да, бюджет. Нужно понимать, что ERP — невероятно дорогое удовольствие.
«для успешного внедрения потребуется сотрудничество с опытными специалистами»
Труд одинэсников, насколько я знаю, сейчас оценивается в районе 2500 р/час. САПёры — в разы дороже. А этих самых часов, рассчитывайте на это сразу, будут человекогоды. По-другому бывает только в сказках.
Кроме всего этого нужно понимать, что всегда есть такая вещь, как риск провала проекта. Реальная успешность внедрения ERP — очень далеко не 100%. Бывает так, что проект не спасает даже нелимитированный финансовый ресурс Заказчика. Ходят легенды о провалах проектов, в которые были вложены миллиарды (!!!) американских рублей.YaMishar
14.07.2017 17:56Вычленение дочки может быть довольно простым делом, если заранее подумать о структуре БД. Скажем иметь бранчи или компании. И чтобы это хранилось в отдельных таблицах (мне так не нравится), либо являлось ключом (на мой взгляд более разумное).
Конечно, бывают ньюансы, недавно вот один клиент продал часть бизнеса, но часть кастомеров своих оставил. Из серии, когда у отца только мельница была, надо было её как-то между сыновьями делить. Но и тут можно подумать о выгрузке, просто это более сложная операция.
Про бюджет — не забывайте, что те же 1С ники предлагают коробочные варианты, и внедрение занимает не человеко-годы, а человеко-недели. Ведь даже фин+налоговая отчётность без производства — это тоже ЕРП. Чему нам быть на годы внедрения?maslyaev
14.07.2017 18:26+1В подавляющем большинстве случаев структура таблиц — реальность, данная нам в ощущениях, поэтому думать о ней можно (и нужно), но что толку?
По опыту скажу, что и заказчики, и внедренцы напрочь не склонны смотреть в динамике на автоматизируемую оргструктуру и бизнес-процессы. Чаще всего игра в ERP начинается тогда, когда выкристаллизовалось новое положение дел, и все пребывают с святой уверенности, что это новое теперь даже если не навсегда, то очень и очень надолго. Даже опытнейшие внедренцы, съевшие в таких ситуациях немерено дерьма, всё равно на этой ерунде регулярно прокалываются.
1С ники предлагают коробочные варианты
Некоторые продукты 1С весьма неплохо подходят для коробочной продажи. Например, «Бухгалтерия», если внедряться без извращений. Куча народу действительно кормится с немудрящего бизнеса в стиле «привезти коробку / поставить / настроить / потом регулярно обновлять», но эта ниша постепенно упраздняется SaaSом. Крупные многомиллионные внедрения 1С с масштабной кастомизацией — весьма рядовое явление, уверяю вас.
Areso
14.07.2017 21:06Смысл ERP не в том, что это разные модули, критичные для бизнеса, а в том, что это управление ресурсами. Деньги (финансовая отчетность) лишь один из ресурсов. Сырье, товары, работники, средства производства — вот далеко неполный список тех самых ресурсов. Даже если у вас есть цех с 3 станками и 5 работниками, грамотное распределение заказов должно иметь место, иначе 1 станок будет загружен сутками, а другие два простаивать. Просто на уровне мелкого цеха — этим рулит мастер в согласовании с единственным продажником, а на уровне предприятия с тысячей сотрудников без нормального управления ресурсами уже не обойтись (имхо).
YaMishar
15.07.2017 08:38А если нет таких ресурсов, как сырьё или товары?
Я понимаю, что существуют имплементации стоимостью миллионы долларов, но есть и имплементации стоимостью в тысячи долларов — от этого они не становятся «неКРП».
Если ваш бизнес — консалтинг и вы имеете 2х сотрудников, то вам достаточно довольно простой инсталяции. Accounts Receivable — максимум.Areso
15.07.2017 09:43В таком случае можно сказать, что и 1С: Бухгалтерия уже ERP система для такого предприятия. Но это такой, как бы вам сказать, очень оригинальный подход. А классический — хорошо изложен везде, от Вики до книг по корп.инф.системам.
DrPass
16.07.2017 01:48Вычленение дочки может быть довольно простым делом, если заранее подумать о структуре БД. Скажем иметь бранчи или компании
Ну вот а как её заранее так продумать? Сегодня вам, допустим, нужна структура, которая позволит легче строить консолидированную отчетность, и вы свои бранчи разделяете как измерения/субконто в общих таблицах документов. И т.к. вы не Нострадамус, вы не станете исходить из того, что через два года руководство решит продать одно подразделение третьей стороне.
OlegZH
16.07.2017 23:12Справедливо. Но вопрос про «заранее» всё-равно никуда не делся. Если чего-то не хватает для преобразования структуры, то, значит, должен быть, как мне кажется, предложен новый механизм или какой-то новый слой абстракции. Если бы такой механизм существовал, то можно было бы говорить о компонентах. Например, можно было бы говорить о компоненте, отвечающим за подразделения.
Было бы очень любопытно узнать о различных попытках предложить что-то «заранее». Наверняка, такие попытки были.
OlegZH
16.07.2017 23:43-1Если в малом бизнесе удается обойтись без этого инструмента, то средний бизнес с каждым днем активнее пользуется подобными средствами.
Наверное, здесь может может быть источник проблемы. Наверное, плохо, если обходятся без какого-либо инструмента. Всегда должен быть какой-то инструмент, удовлетворяющий всем, хотя бы и минимальным требованиям.Перечень критически важных данных и та их часть, которую обязательно нужно обрабатывать в ERP системе, вычисляются эмпирически для каждого конкретного бизнеса. Именно анализ этих данных и правильное их определение дает ответы на вопросы: есть ли необходимость в покупке и внедрении ERP системы, и оправдаются ли затраты на этот вид автоматизации бизнеса.
А почему не поступают противоположным образом? Почему нельзя попытаться провести системный анализ целой предметной области, тщательно классифицировать все типы данных и процессов и задать правила формирования программных систем (для данных и процессов заранее определённых классов), допускающие задание таких свойств, как статичность/динамичность, компактность/масштабируемость и т.д. и т.п.
Современные исследования в области СУБД, как раз, говорят о возможности создавать многоуровневые СУБД, где, например, может быть выделен особый слой управления файлами, позволяющий создавать секционирование таблиц баз данных. Секционирование таблиц — это попытка уйти от жёсткой реляционной структуры в сторону NoSQL. В этом смысле, приведённый выше в обсуждении пример с отделяющийся дочкой хорошо подходит под секционирование, когда единая таблица разбивается на более мелкие, которые, также, могут рассматриваться как самостоятельные таблицы. Секционирование позволяет, таким образом, рассматривать в рамках одной схемы метаданных сразу несколько схем данных.
Просто, если попытаться расписать некий полный вариант системы (чисто теоретически), то получится, что во всех, даже, очень простых случаях придётся использовать все уровни описания, хотя, эти уровни (в простых случаях) и будут тривиальными. Говорят, что «серебряной пули» не существует. Но, может быть, эти самые элементарные уровни описания существуют?
В любом случае, как ни крути, получается, что готовая система всегда должна быть индивидуально подогнанной под «фигуру» заказчика. В этом смысле, автоматизацию предприятия можно сравнить с работой в… 1C, когда Вы старательно заполняете базу данных учётными данными, а потом строите по этим данным отчёт. Так и программная система: Вы все предлагаете «коробочную версию», а, потом, сообщаете нам о необходимости доработок и трудностях при внедрении, а следовало бы ожидать увидеть, сначала, некий изначальный прототип системы, составление и проведение разного рода «документов», отражающих пользовательские требования, заполнение соответствующих регистров и, в качестве финального аккорда, выход готового продукта. Но до того момента, пока сам продукт не вышел, он существует только в виде проекта, код которого распределён по базе данных вместе с элементами пользовательского интерфейса. Разве не так?JustRamil
17.07.2017 02:35Просто, если попытаться расписать некий полный вариант системы (чисто теоретически), то получится, что во всех, даже, очень простых случаях придётся использовать все уровни описания, хотя, эти уровни (в простых случаях) и будут тривиальными. Говорят, что «серебряной пули» не существует. Но, может быть, эти самые элементарные уровни описания существуют?
«Просто», «чисто», «теоретически», «некий», «в простых случаях», «говорят» — только в теории все просто может быть.
Разве не так?
У вас вопрос очень неконкретный, перечел ваш комментарий несколько раз и так так и не понял суть вашего вопроса. Слишком у вас много теории.OlegZH
17.07.2017 21:00Да, у меня очень много вопросов. А главный вопрос такой: почему сообщество разработчиков программного обеспечения не пытается объединить свои усилия для того, чтобы максимально (насколько это возможно) обобщить свой опыт и предложить некий «наибольший общий делитель» всех разрабатываемых систем? Мне кажется, было бы крайне полезно обменяться опытом и рассмотреть различные типы задач и различные же решения одних и тех же задач. Здесь нужна какая-то глубокая классификация, а без теории её будет невозможно сделать. И, вообще, где теория разработки корпоративных систем? Разве эти работы, теоретические исследования не ведутся? По крайней мере, обмен опытом мог бы позволить увидеть всю проблему в объёме. Причём, заметьте, здесь важны и нужны как положительные, так и отрицательные результаты!
Давайте посмотрим на проблему с самого низа. (Ниже, я формулирую несколько очевидных вещей.)
Предположим, Вы начинаете разрабатывать некую систему «с нуля». Вы создаёте простую модель данных, где многие вещи хранятся непосредственно в столбцах весьма немногочисленных таблиц, что обеспечивает простоту составления запросов. Нормализация (и другие соображения) заставляет Вас создавать дополнительные таблицы для адекватного представления реляционных отношений. Пока структура базы данных статична, всё хорошо, все оптимизировано (или всё потенциально может быть оптимизировано) и надёжно. Если Вам нужно предусмотреть возможность изменения структуры и Вы хотите автоматизировать создание пользовательского интерфейса, то Вам придётся серьёзно упорядочить структуру таблиц базы данных и ввести некоторый стандарт на типы и имена столбцов. Вы, наверное, задумаетесь над тем, где, на самом деле, должны храниться те или иные данные, и тогда окажется, что Вам придётся вводить довольно много разного рода явных описаний хранимых данных (метаданных) и предоставлять особые механизмы для управления этими метаданными. Основное отличие простых систем от сложных состоит именно в степени формализации метаданных. В самых простых системах метаданных нет, и многое находится в головке у служащих. Сложные системы «из коробки», как я понимаю, уже предлагают определённый набор метаданных и средств управления ими…
Тут очень помогли бы примеры реальных разработок и примеры фигурирующих в них метаданных и, вообще, примеры подходов к организации хранения и обработке данных…
Вот почему мне кажется, что было бы очень неплохо заняться классификацией задач, процессов и объектов управления и поиском адекватного представления данных для каждой предметной ситуации. Я предлагаю Вам помощь, а Вы мне минус «ставите» и говорите, что у меня много «теории», хотя, именно теории здесь явно не хватает, поскольку всем разработчикам и заказчикам нужен некий объективный инструмент анализа, позволяющий выбирать из множества вариантов реализации тот, который лучше всего подходит к каждой конкретной ситуации.
Мне было бы крайне интересно попытаться рассмотреть различные предметные ситуации, возникающие в деятельности предприятий, и сопоставить возможные решения. Тем более, что, создавая самописное программное обеспечение для медицинских диагностических комплексов, я обнаружил, в один прекрасный момент, что здесь возникают, по сути, те же вопросы, задачи и проблемы, что и при разработке ERP-систем, а это значит, что здесь нужное некое системное решение. А системное решение может быть результатом только системного подхода и системного анализа предметной области (любой).
Да, я — новичок в этой теме. Скажем так, по возрасту, я должен был бы сам разрабатывать такие ERP-системы и, вообще говоря, пропустил очень много «серий». Но я готов с жадностью впитать чужой опыт, прочитав разного рода статьи (включая и статьи Вас и Ваших коллег).
Слишком у вас много теории.
Для меня все поставленные выше вопросы носят практический характер, поскольку я собираюсь для каждого вопроса разрабатывать схему данных и код. Очень хочется попробовать это всё на практике. А успешные пробы — хороший материал для статьи. Но, уже, содержащей одни только ответы. Но без грамотной теории к правильным ответам никогда не придти.DrPass
17.07.2017 21:27+1А главный вопрос такой: почему сообщество разработчиков программного обеспечения не пытается объединить свои усилия для того, чтобы максимально (насколько это возможно) обобщить свой опыт и предложить некий «наибольший общий делитель» всех разрабатываемых систем?
Затем же, зачем это не делают производители автомобилей и шоколадных батончиков. Да и клиентам оно не особенно нужно. Вы же не хотите есть только один универсальный батончик с оптимально подобранным вкусом? Вот и рынок ERP не нуждается в одной универсальной системе, которая как-то усреднённо решает потребности всех клиентов, кому-то лучше, кому-то хуже.
И, вообще, где теория разработки корпоративных систем?
А на какие вопросы эта теория должна давать ответ? Как лучше делать управление складом? Как строить производственные цепочки? Это уже давно описано, изучено и оптимизировано. Чтобы перенести это на язык СУБД и какой-то язык программирования, дополнительная теория не нужна, нужны обычные разработчики.
Вы, наверное, задумаетесь над тем, где, на самом деле, должны храниться те или иные данные, и тогда окажется, что Вам придётся вводить довольно много разного рода явных описаний хранимых данных
Вы знаете, при разработке ERP этот вопрос находится где-то на самой последней странице хит-парада, где-то между вопросами «делать на клиенте обычные тулбары или риббоны» и «сколько места выделять под тестовую БД». Это сугубо техническая деталь, которая архитектором закладывается в схему данных «by default».OlegZH
18.07.2017 15:14Это уже давно описано, изучено и оптимизировано. Чтобы перенести это на язык СУБД и какой-то язык программирования, дополнительная теория не нужна, нужны обычные разработчики.
Это Ваше утверждение, которое я никак не оспариваю и, скорее, поддерживаю, поскольку грамотная реализация хорошей схемы обязательно будет хорошо работать (если не работает, то проблемы в реализации), но… это никак не стыкуется с описанием реальных проблем (например того, что фигурирует здесь в комментариях под названием «так исторически сложилось») и основным посылом самой статьи. Если бы всё, действительно, было «уже давно описано, изучено и оптимизировано», то всё упиралось бы только в наличие рукастых программистов, которые смогут добротно воплотить в жизнь чёткую и продуманную схему. Видимо, здесь что-то не так, и имеются серьёзные проблемы.Вы знаете, при разработке ERP… Это сугубо техническая деталь
Боюсь, я был неправильно понят. Я написал про разработку большой системы «с нуля».
И, вообще, Ваша реплика оставляет меня в некотором недоумении.
Во-первых, как схема/модель базы данных (концептуальная, логическая и физическая) может быть сугубо технической деталью? Как Вы, в целом, представляете процесс разработки ERP-системы? Какие есть этапы и какие задачи необходимо решить? (В двух словах. Чтобы я мог получить верное представление и ничего не путал, если уже успел запутаться по Вашему мнению.)
Во-вторых, хотелось бы знать, как «лучше делать управление складом»?
И, наконец, может быть, самое интересное, что хотелось бы услышать от Вас (после всех Ваших слов): с каким опытом разработки/внедрения ERP-систем Вы сталкивались? Что хорошего принесло их внедрение? Каковы были трудности (организационные, технические)? Какие здесь есть актуальные и интересные (решённые/нерешённые) задачи?
P.S. Лично я очень хотел бы полностью расписать для себя всё, что связано, например, со складом. Но у этой росписи будет значительно больше пользы, если я познакомлюсь с промышленными решениями и смогу написать своими скромными силами свои решения, чтобы хорошо почувствовать специфику предметной области. Вы мне не поможете в этом вопросе?Drac013
18.07.2017 16:24Позвольте от себя добавить несколько замечаний.
ERP системы ближе всего к деньгам предприятия. Примерно так же близко, как учет транзакций для банков и тому подобные критичные системы. Именно поэтому в плане изменения этих систем бизнес крайне инертен. Он боится что-либо менять без конкретных причин, рассчитанного эффекта, минимизированных рисков. И даже после расчета всех этих факторов все равно боится. Потому что это деньги. Зачастую огромные деньги.
Как итог, многие модули подобных систем работают десятки лет (вспоминаем COBOL). Конечно, любому гику и программисту может показаться это диким, но таков закон бизнеса в отношении ERP и критичных систем: пока нет явных причин, менять ничего не будут. Конечно, бывают исключения, но их не так много.
Дальше. Когда чистый программист (или группа программистов) берется за разработку прикладного решения для бизнеса (не важно, WMS, SCM, PLM и многие-многие другие) без реального (и, желательно, очень большого) опыта работы в этой отрасли, то в 100% получается технически передовое, архитектурно выверенное, логически прекрасное, но… абсолютно ненужное бизнесу решение. По книжкам, по примерам можно что-то понять, но только до уровня, когда вы сможете вникнуть в суть проблем и задач, которые поставит перед вами методолог.
Конечно, возможны варианты, когда программист погружается в предметную область до уровня эксперта. Но это возможно только при длительном времени работы над проектами в конкретной области, при участии во внедрении на реальных предприятиях, при поддержке таких решений в эксплуатации. Т.е., по факту, при работе в этой области на протяжении долгих лет.
И, наконец, может быть, самое интересное, что хотелось бы услышать от Вас (после всех Ваших слов): с каким опытом разработки/внедрения ERP-систем Вы сталкивались? Что хорошего принесло их внедрение? Каковы были трудности (организационные, технические)? Какие здесь есть актуальные и интересные (решённые/нерешённые) задачи?
Ну и на данные вопросы вам никто исчерпывающе не ответит. По той простой причине, что область ERP слишком обширна. Это как спросить, какие актуальные и интересные задачи есть в программировании.OlegZH
19.07.2017 16:43В целом, я и сам понимаю это всё примерно также. Хотя и со стороны. Но мой интерес в том, чтобы, если понадобится (я на это надеюсь), войти в эту область.
zw_irk
17.07.2017 11:19Многие конторы адаптируют не ERP под свои бизнес процессы, а свои бизнес процессы под ERP. После такого внедрения получается очень странная ситуация — компании с ERP от одного вендора становятся похожи внутри друг на друга. Что наверное в дальнейшем облегчит слияние таких компаний, но вряд ли усилит их конкурентоспособность. Зато интегратору проще внедрять и куда проще сопровождать одинаковые компании с похожими процессами :).
Вывод очевиден: заказчик должен чётко понимать недостатки и преимущества своих процессов, чтобы в процессе внедрения не потерять свою яркую индивидуальность и свои преимущества :)DrPass
17.07.2017 12:21Вывод очевиден: заказчик должен чётко понимать недостатки и преимущества своих процессов, чтобы в процессе внедрения не потерять свою яркую индивидуальность и свои преимущества :)
Это делается чаще не ради упрощения работы интегратора, а для того, чтобы уменьшить стоимость внедрения ERP с сундука платины до хотя бы сундука с золотом. В большинстве случаев намного дешевле и менее больно изменить бизнес-процесс, чем писать под него автоматизацию по прайсу внедренца Axapta или SAP, потом ещё тестировать и отлаживать это :)zw_irk
17.07.2017 13:48В большинстве случаев намного дешевле и менее больно изменить бизнес-процесс, чем писать под него автоматизацию по прайсу внедренца Axapta или SAP, потом ещё тестировать и отлаживать это :)
Вот это принципиальное решение, меняем бизнес-процесс под ERP или меняем ERP под бизнес-процесс, должно быть очень взвешенным. Изменение одного процесса может потянуть изменения в других процессах, что в итоге обойдётся не в один сундук платины (это сколько только регулирующих документов поменять надо), так и может снизить эффективность работы процесса. Он же такой уникальный, не потому что у людей, которые его выстраивали годами, был цель сделать уникальный процесс, шоб все обзавидавались:)
PS. Есть пара историй, когда во внедряемой ERP процесс был стандартизирован по ERP, а за пределами ERP всё оставалось по старому. В результате персонал вёл двойную документацию, одну в ERP, другую в документах и старых АСУ. Было прикольно:) Со временем, конечно, всё пофиксили, но очевидно, что этого можно было и не допускать.DrPass
17.07.2017 14:00Вот это принципиальное решение, меняем бизнес-процесс под ERP или меняем ERP под бизнес-процесс, должно быть очень взвешенным.
Во внедрении ERP сложно найти решения, которые не должны быть очень взвешенными :)
Он же такой уникальный, не потому что у людей, которые его выстраивали годами, был цель сделать уникальный процесс, шоб все обзавидавались
Вот по моим наблюдениям (это только мои наблюдения, на объективность не претендую) большинство бизнес-процессов на предприятиях, которые ещё не лишились девственности со стороны системного анализа и ERP, это результат многолетнего «так само сложилось», «привыкли» и «а что, можно по-другому?». И единственной причиной (кстати, очень серьезной), которая будет препятствовать его переделке и оптимизации, это п. 2 «привыкли». В таких случаях очень важна поддержка и понимание со стороны топ-менеджмента компании. Если они директивно заставят внедрять новые процессы, то система «взлетит». Сотрудники переучатся, за небольшой период времени устранят подводные камни и отдебажат новые процессы, и вскоре никто и не вспомнит, что раньше работали иначе. Если топ-менеджмент дает внедренцам денюжку, и отмахивается, «сами занимайтесь», то не взлетит. Сотрудники будут тихонько саботировать, бережно хранить старые зомби-процессы, и работа только усложнится.OlegZH
17.07.2017 21:12Наверное, здесь может быть применён мультиагентный подход, когда на рабочие места устанавливаются обыкновенные мессенджеры, и тогда, на начальном этапе разработке системы, хотя бы проявляется реальная структура управления, становятся видны узкие места и зазоры в управлении. А уже потом можно будет «навешивать» более сложный интерфейс и заменять, где надо, реальные цепочки цепочками агентов. Получается что-то вроде эскизного создания системы + элементы самоорганизации. Зато можно увидеть разницу между ДО и ПОСЛЕ и понять, стоит ли переучиваться.
(Раньше я думал, что всё это — мои вольные фантазии, но современное развитие мультиагентного подхода пошло именно в этом направлении.)
А, вообще, это самое «так исторически сложилось» — самый что ни есть бич любой автоматизации. Без неё, вроде бы, и более спокойно.
zw_irk
18.07.2017 04:39Вот по моим наблюдениям (это только мои наблюдения, на объективность не претендую) большинство бизнес-процессов на предприятиях, которые ещё не лишились девственности со стороны системного анализа и ERP, это результат многолетнего «так само сложилось», «привыкли» и «а что, можно по-другому?».
Я с этим соглашусь, оно так и есть. Но ведь после внедрения ERP спустя год-другой пройти и спросить, а почему бизнес-процесс такой (или а почему вы делаете так?) вам ответ будет примерно такой же:D Только появится ещё вариант: так система ERP хочет.
В этом нет вины какой-то техники, просто на этом предприятии никто не занимается организацией бизнес-процессов. Оно и продолжает складываться исторически, от распоряжения к распоряжению.
PS.Я помню шедевральный случай, когда человек пошёл в бухгалтерию с вопросом, а почему зарплата такая? Ответ был: так система посчитала. Он попросил объяснить из чего складывается его зарплата, но бухгалтер не смогла ничего, кроме «так система посчитала» внятного сказать.
OlegZH
1. Верно ли, что различные ERP-системы, по сути, содержат одни и те же элементы, и их создатели тратят, таким образом, много времени на кодирование одного и того же?
2. Можно ли каким-нибудь образом автоматизировать создание ERP-систем?
3. Существует ли возможность связывать различные ERP-системы у различных контрагентов (по отношению к друг другу)?
4. Возможно сделать так, чтобы при создании некой новой ERP-системы (в её полном развёрнутом варианте) заложить в ней некие более оптимальные, чем общепринятые, способы организации труда, а при внедрении автоматически оптимизировать работу самого предприятия?
JustRamil
По большей части — да. В наше время очень сложно придумать что то новое в такой сфере как автоматизация бизнеса.
В точки зрения разработки — автоматизировать можно. Вопрос в том кто это оплатит и кто это потом купит.
Да. С точки зрения интеграции ERP ничем не отличаются от остальных IT систем для автоматизации бизнеса.
Да. Во многих ERP создатели сразу закладывают функционал с учетом Best practices.
anatolius
На практике я видел как производственные процессы переделывали под то, что заложено в ERP хотя экономически это не было оправдано, но так было удобнее для системы.
DrPass
Производственные процессы под ERP переделывают обычно в крайнем случае, когда надо натянуть сову на глобус. Производственные процессы определяются ведь технологией производства и возможностями оборудования. Поэтому если говоряд об оптимизации работы предприятия, то как правило, речь идет о переделке бизнес-процессов. Грубо говоря, порядки прохождения бумажек, согласований и т.д. Во многих случаях, если предприятие ранее не автоматизировалось, бизнес-процессы там построены по принципу «так сложилось исторически», и простор для внедрения лучших практик там немалый.
OlegZH
Я это, примерно, и имел в виду.