|
MainFrameВопросы по системе задам. Вопрос сопровождения и быстрой реакции на изменяющиеся бизнес-процессы думаю скоро станет (если уже не стал) краеугольным камнем развития крупных корпоративных систем. Каким образом это решается у Вас? Как я понимаю, Ваша система позиционируется именно в этом отличной от других. Может быть, и концептуально и практически? Существуют разные подходы к созданию систем. В основе реализации практически всех известных ERP-систем лежит т.н. case-method. По своей сути, этот метод состоит в том, что исходная модель «списывается» с одного или нескольких успешных предприятий. Если посмотреть на книги по проектированию, то и они говорят о том же: «Первый этап проектирования представляет собой анализ требований пользователей». Следствием применения данной методики является получение множества частных решений, высокая трудоемкость создания системы, потребность в описании бизнес-процессов на каждом конкретном предприятии, значительная трудоемкость внедрения и сопровождения, недовольство специалистов предприятия (технологов, плановиков, экономистов и пр.) и т.д.
В основе системы «КУБ» лежат семантические модели. Они очень просты и легко воспринимаются руководителями. Их значительно проще реализовывать, внедрять, сопровождать и развивать. Пример модели промышленного предприятия есть в разделе «планирования». При внедрении системы основной упор делается на раскрытие и донесение смысла деятельности до руководителя с последующим обучением использованию программного обучения (собственно, все внедрение состоит из двух функций объяснения и заведения нормативно-справочную информацию). Описывать бизнес-процессы нет никакой необходимости, вместо этого на основе предлагаемых моделей совместно с руководителями предприятия делается анализ организационной структуры предприятия. Важно, чтобы руководитель сам сформулировал существующие проблемы и способы их решения. Это дает определенную гарантию того, что при изменениях во внешней среде или на самом предприятии, руководитель сможет принять правильное решение. А система обладает достаточной гибкостью для реализации любого решения в рамках здравого смысла (семантика (смысл) заложена в исходные модели).
MainFrameпредполагается , что в крупном предприятии система будет работать на нескольких севрерах. При этом разные подсистемы на разных серверах. Каким образом реализована интеграция ? Данные реплицируются? или сразу используется непосредственный доступ на другие базы? Когда Вы говорите о распределении нагрузки , что Вы имеете в виду ? распределение по функционалу? т.е. бухгалтеры работают с одним серверов, а кадровики с другим? Что представляет собой клиент- это веб-приложение? Да, каждая подсистема может располагаться на отдельном сервере. В этом основа повышения масштабируемости и надежности системы. Есть специальная подсистема «Интегратор», которая отвечает за поддержание единого информационного пространства предприятия. Каждая подсистема работает, как с уникальной информацией, так и с информацией разделяемой с другими подсистемами. Разделение информации основано на частичной, многосторонней, асинхронной репликации. В системе может быть установлено несколько подсистем одного типа. Добавление новых подсистем, равно, как и удаление существующих, выполняется в штатном режиме без остановки системы. То есть, если на предприятии проходит реструктуризация, то система «КУБ» сохраняет свою актуальность и автоматизирует данный процесс.
MainFrameВозможно ли использование отдельных подсистем, в которые данные будут импортироваться из других. Например, нас интересует только планирование. Можем ли мы импортировать в него необходимые даные из других систем Принципиальных ограничений на выполнение «экспорта/импорта» нет. Что касается «планирования», то здесь могут быть проблемы. Дело в том, что в системе «КУБ» планирование отвечает за полноту и непротиворечивость текущей конфигурации системы. Если внешние данные не отвечают этим требованиям, то они будут отвергнуты. Здесь важно понимание сути планирования, не как отдельного акта/процесса, а как жизненно важного элемента системы. К сожалению, планирование в ERP-системах – одно из самых слабых мест.
MainFrameВы настаиваете на отказе от описания бизнес-процессов. Я не фанатик их описания в любой ситуации. Но в некоторых...лучше на примере. Есть некий сложный процесс, в котором участвуют множество людей, они согласовывают кучу объектов, заявки на объекты возвращаются по множеству раз от субъекта, к субъекту, и в конце, концов из множества согласованных объектов, выполняется расчет некоторой интресующей нас в данный момент сущности. Процесс согласования при этом разнесен по времени. Так как часть объектов согласовываются в мае, следующая порция в сентябре и часть в феврале. Участвуют в согласовании множество отделов и руководителей. Каким образом без описания такого запутанного процесса, можно настроить Вашу систему? Да и почему нужно принципиально не описывать? Описание – не цель, но средство... средство понимания сути. Можно ли гарантировать то, что описания бизнес-процессов передают суть? Или, говоря более формально, есть ли способы верификации описаний бизнес-процессов? Увы... Можно провести аналогию с определениями. Определение любого термина и понятия должно передавать их существо (смысл). Но всегда ли это так? Когда мы работаем с руководителями, то просим их определить смысл основных понятий, таких, как производство, склад, финансы и пр. ... всего одним словом. Если руководитель понимает смысл, то проекцию сделать проекцию смысла на действительность (которая постоянно меняется) для него не составит никаких проблем. Кейнс однажды сказал: «Все глупости в экономике происходят из-за непонимания элементарных вещей». Думаю, что в этом он был прав.
|
