Я очень рада , что участников дискуссии прибыло!
Думаю, что надо немного более корректно определить понятие «модульность» ,ну чтобы далее можно было уже продвинуться не в обсуждении какие программы лучше или хуже , а именно по проблематике автоматизации. Ибо автоматизация – это не только ПО , я бы даже сказала ,НЕ СТОЛЬКО ПО.
Упрощенно модель клиент-серверной технологии выглядит так : сервер баз данных +клиент для внесения/изменения/обработки информации , которая хранится на сервере баз данных.
Если мы «модульностью» называем архитектуру :модуль1+модуль2+модуль3 +…, где каждый модуль =база+клиент , то да , Serje прав, это абсолютное зло. Причем тут уже совершенно все равно ,на каком языке программирования это «зло» написано, ну разве степень «зла» чуточку варьируется .( Но сути это не меняет) Об этом как раз очень красноречиво рассказывается по ссылке уважаемого Serje. И его пост на самом деле , не опровержение моих тезисов, а очень даже подтверждение. Ведь мои тезисы касались «модульности» несколько иной : когда имеется единая база данных, с которой работают различные модули , ну или «рабочие места» , если хотите. Вот только на сегодняшний день у нас таких систем для полноценного описания всего бизнес-процесса просто нет , от слова «совсем». Возможно , какие-то зарубежные программы и способны на это , но , во-первых , их приходится все равно дорабатывать под российские реалии ,и цена таких доработок плюсуется к базовой (весьма нехилой) стоимости самого продукта . Ну и имеем то , что имеем.
Про «коробочные» продукты я уже писала в другой ветке, и смысл такой(неважно какой участок бизнес-процесса автоматизирует такой продукт) : если вас все устраивает в «коробочном» варианте , то зачем вам открытый код и мощный настроечный механизм? А вышеупомянутые тезисы про «коробочный продукт» касаются ПО без открытого кода и с минимальным количеством настроек. Ну да, согласна , не совсем корректно называть такой продукт «коробочным», предлагаю термин «условно коробочный». И совершенно согласна с тем , что «условно коробочный» продукт должен развиваться в соответствии с увеличивающимися нуждами пользователя. Кстати , чем больше у разработчика линейка продуктов , тем труднее обеспечить такое развитие. Почему, думаю , пояснять не надо.
Теперь плавно переходим к общей проблематике автоматизации.
Скрытый текст
Если мы строим автоматизацию по типу «абсолютного зла» , т.е. каждый модуль работает с отдельно стоящей базой данных , то даже красиво и толково автоматизировав какой-то кусочек бизнес -процесса , автоматически получаем целый букет проблем. Например ,синхронизация справочников и журналов документов , куча проблем импорта-экспорта данных, особенно когда это все касается сразу нескольких подразделений на предприятии, и данные нужны в режиме онлайн . Приходится расписывать массу регламентов на тему «кто , что и когда», и все равно это не панацея , ибо человеческий фактор никто отменить не может, во всяком случае в ближайшее время. Но есть предприятия (обычно сильно маленькие), где с этим справится возможно .
Впрочем , все это можно прочесть по ссылке Serje. Хоть там это и пишется применительно к 1С , но если брать программы написанные на любых других языках программирования– сути это не изменит. И это я еще не говорю об «итальянских забастовках» (это когда пользователь попросту игнорирует все инструкции или просто не хочет работать в программе)…. А еще есть тема : на предприятии каждый работник выполняет свою функцию и при обустройстве для него рабочего места надо уметь разговаривать с ним на одном языке. ( Много вы видели программистов , которые умеют разговаривать с бухгалтерами и управленцами на их языке?
) Ну и т.д., и т.п.
[свернуть]
В свете всего вышесказанного , мое мнение такое : давно уже пора бизнес-процесс автоматизировать не по частям , как это у нас несколько десятилетий делается, а рассматривать все его части как единое целое. При таком подходе логично предположить, что как можно больше информации обо всех участках бизнес-процесса надо хранить в единой базе данных, и различные модули должны иметь доступ к нужной этому модулю части информации . При такой схеме мы, для начала ,минимизируем количество информации , которую надо будет импортировать/экпортировать и синхронизировать . Уже легче. Кстати, надо сказать , что есть и модули , работа которых на общей БД скорее вредна , нежели полезна. И тут вполне достаточно толково организовать экспорт информации.
Пока что , при всем моем уважении к производителям ПО (и 1С и не 1С), подход у нас идет по первой модели «модульности», а это бег по кругу. И да , придя к мысли о единой БД надо понимать , что малейшая ошибка при ее конструировании может обойтись очень дорого. Вот тут-то меня и настораживает проблематика конструирования и видоизменения БД при использовании системы 1С . Ведь даже очень хороший программист , увы, не всегда обладает нужной квалификацией в построении БД. (Имея хорошо настроенное пианино : один на нем «Лунную Сонату» виртуозно сыграет , а у второго только Чижик-пыжик одним пальцем получится; И - любой настройщик умеет играть на пианино , но не каждый пианист в состоянии пианино настроить
)
Тут еще вот какой есть момент: большому и среднему бизнесу абсолютно некогда заниматься всей этой казуистикой. Да и немногие бизнесмены смогут написать толковое ТЗ на автоматизацию .Приходим к выводу, что необходимы консалтинговые услуги и т.н. «внедрение».
А следующий шаг , это когда мы придем к вполне , на мой взгляд, логичному выводу , что нужен не столько открытый код , сколько знание где и что хранится в базе данных . И вот тогда наши мечты начнут "офигевать" от наших возможностей.
Скрытый текст
Когда-то много лет назад мы занимались автоматизацией на предприятии молочной промышленности .Так вот однажды была забавная ситуация . Надо было подключить несколько ноутбуков , а шнур питания у одного из ноутбуков не дотягивался до розетки . Три технических специалиста готовы были уже бежать в магазин за удлинителем . Пришлось подсказать им гениально простую мысль : просто переставить столы. Это я к чему : инертность в мышлении очень часто нас подводит.
[свернуть]