В статье //infostart.ru/public/192074/ описывается подход к разработке модульного приложения. Эта статья продолжает тему модульности и посвящена модели распространения модулей до конечных заказчиков.
В глобальном смысле возможны две схемы работы клиента: в режиме сервиса (Saas) и локально (On-site); режим работы в сервисе делится ещё на два вида: в общем сервисе (единая разделённая база) и выделенная база на сервере для клиента. Причём разные модули у одного клиента могут располагаться в разных местах: Модуль1 – в общем сервисе, Модуль2 – в отдельной выделенной базе на сервисе, Модуль3 – локально на севере предприятия. Все эти модули могут взаимодействовать друг с другом и иметь общие сквозные данные и процессы. Механика такого взаимодействия — это отдельная тема и в данной статье обсуждаться не будет.
За учёт характеристик клиента, набора купленных им модулей и используемых баз отвечает управляющая система.
Разработка модулей может вестись разными командами разработки независимо, но, в конечном итоге, все модули попадают в одно общее хранилище конфигурации. Типовые поставки клиентам делаются на основе конфигурации последнего стабильного релиза, из специальной базы (база для поставок). Если сопровождение изменённой конфигурации клиента ведётся компанией владельцем сервиса, то существует также хранилище изменённой конфигурации под конкретного клиента, и поставка делается на основе него. Здесь будет уместно сказать, что мы понимаем под изменёнными конфигурациями – нами рассматривается вариант, что вся доп. функциональность, разрабатываемая под клиента, включается в типовую конфигурацию как модули, доступные только для этого клиента, т.е. при наличии такого доп. модуля, с точки зрения системы, конфигурация остаётся типовой; изменённая конфигурация в такой постановке может быть только в следующих случаях: модуль внедрён в другую систему, заказчиком вносятся изменения в конфигурацию самостоятельно или функционал типовых модулей изменяется таким образом, что его нельзя оформить как доп. модуль.
Пара слов о версиях конфигурации и модулей:
Типовая конфигурация имеет единую версию, версии модулей хранятся отдельно. Если конфигурация встроена в другую систему, то её версия состоит из нескольких частей – наша версия и версия системы. Если модуль изменяется под клиента, и функциональность этого изменения по каким-то причинам не может быть выделена в отдельный модуль, то версия модуля также состоит из 2х частей – типовая версия и версия поставки клиенту.
Обновление версий модулей осуществляется перед поставкой нового типового релиза конфигурации.
Проследим действия человека и управляющей системы при покупке новых модулей:
|
|
ЧЕЛОВЕК |
СИСТЕМА |
|
1 |
Заходит в магазин приложений, вводит логин, пароль и идентификатор базы, для которой он собирается совершить покупку.
|
Происходит аутенфикация пользователя в системе. |
|
2 |
Выбирает нужные модули, кладёт их в «корзину» |
Проверяются связи модулей – если для работы выбранного модуля необходим модуль, ранее не приобретённый клиентом или не добавленный в корзину, то его покупка не доступна. Также осуществляются проверки совместимости модулей с текущей версией конфигурации у клиента. |
|
3 |
Нажимает кнопку «Оформить заказ» |
Создаётся документ «Заявка». При проведении документа ещё раз проверяется корректность всех данных, в т.ч. набора выбранных модулей. |
|
4 |
Выбирает способ оплаты, заполняет поля оплаты, нажимает «Оплатить» |
Осуществляется биллинг платежа, создаётся документ «Оплата», при проведении которого записывается информация о новых купленных модулях клиента. При необходимости выписываются документы для отчётности. |
|
5 |
Если целевая база клиента в сервисе – то администратору автоматически становятся доступны роли и настройки новых модулей; если локально – в личном кабинете пользователя магазина появляется ссылка на скачивание комплекта поставки |
Запускается механизм поставки модулей.
|
Теперь подробно рассмотрим пятый пункт с точки зрения работы системы.
Конечная цель механизма – сделать процесс доставки нового модуля до клиента удобным и быстрым. Для этого в процессе поставки необходимо максимально исключить ручной труд технического специалиста.
Для определения процесса поставки по конкретному заказу нужно ответить на следующие вопросы:
- Целевая база находится в сервисе или локально?
- Конфигурация целевой базы содержит изменения по сравнению с типовой поставкой?
Она сопровождается нами, или клиент вносит туда изменения самостоятельно? Нам доступна изменённая конфигурация целевой базы? - Конфигурация целевой базы имеет последнюю версию типовой поставки?
- Какие модули необходимо поставить клиенту?
Вся информация по этим вопросам хранится в управляющей системе в разрезе клиента и базы. В зависимости от ответов на них, механизм поставки можно полностью или частично автоматизировать.
В процессе поставки новых модулей клиенту можно выделить следующие операции:
- создание файлов комплекта поставки, содержащего нужный набор модулей;
- тестирование поставки;
- обновление поставкой целевой базы;
- запуск необходимых обработчиков для инициализации новых модулей и обновления существующих.
Сам механизм поставки в управляющей базе должен быть оформлен как настраиваемый бизнес процесс, максимально разбитый на элементарные операции. Это нужно для того, чтобы варьировать процесс поставки в зависимости от разных входных условий.
Обсудим технические моменты реализации некоторых операций поставки:
1. создание файлов комплекта поставки, содержащего нужный набор модулей
Процесс создания файлов поставки легко автоматизируется с помощью параметров командной строки в режиме запуска конфигуратора.
С помощью новой возможности платформы, добавленной в 8.3, конфигурация выгружается в файлы (/DumpConfigToFiles), те программные модули, которые не должны поставляться, очищаются, и далее конфигурация загружается в специальную базу (/LoadConfigFromFiles), из которой делается целевая поставка (/CreateDistributionFiles).
В глаза бросается, что при данном подходе мы не «вырезаем» непоставляемые объекты метаданных, а только очищаем их программные модули. Решение не выделять в поставке наборы необходимых метаданных обосновано тем что: 1) разработка такого механизма трудозатратна, а плюсы, кроме уменьшения общего количества таблиц в целевой базе, не очевидны; 2) возможен сбой всего процесса поставки, если по какой-то причине (например, по ошибке разработчика модуля, не указавшего все внешние связи) в поставляемом модуле оказались ссылки на непоставляемые объекты.
Ещё один момент, который вытекает из этого решения – файлы поставок должны делаться на машине по управлением ОС Windows (может быть здесь я не прав и пакетный режим запуска работает на Linux клиенте, если это так прошу сказать об этом в комментариях)
2. тестирование поставки
Исходя из алгоритмов в п.1, обязательно тестирование на синтаксический контроль конфигурации. Другие виды тестирования (например, запуск сценарного тестирование под конкретный набор модулей) является опциональным, т.к. всеобъемлющее тестирование – это задача этапа создания типовой поставки нового релиза конфигурации (которая делается не автоматически, а под пристальным контролем специалистов), а не поставки набора модулей под конкретный заказ (при которой важным критерием становится время затраченное клиентом от факта оплаты до доставки купленных модулей)
3. обновление поставкой целевой базы
Данный пункт актуален только для баз расположенных локально (on-site) или выделенных в отдельную базу на сервисе. В первом случае обновление происходит специалистом заказчика с помощью файла поставки самостоятельно; во втором случае обновление возможно автоматически (если конфигурация типовая), или специалистами сервиса (если конфигурация изменённая) – клиент выбирает только желаемое время обновления базы.
4. запуск необходимых обработчиков для инициализации новых модулей и обновления существующих.
Для варианта «Saas» запускается специальный служебный сеанс, в котором осуществляются все необходимые обработки обновления; для варианта «on-site» — обработчики запускаются при первом входе пользователя в систему.
Выводы
Таким образом, мы полагаем, что процесс доставки отдельных модулей до конечного клиента в большинстве случаев можно полностью автоматизировать. Это позволит сделать систему удобной и сократить издержки на её сопровождение.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Правильно ли я понимаю, что пытаетесь изобрести ?
(1) Такая аналогия уместна, с учётом специфики разработки на 1С.
С пользовательской точки зрения это будет выглядеть скорее как магазин мобильных приложений.
(2) как планируете решать конфликты? В 1С то нет 3х стороннего сравнения и если смотреть на стрелочки от «Хранилище типовая» до «Хранилище клиента» — то очень трудоемкий процесс в этих простых стрелочках заключается.
(3) Какие конфликты Вы имеете в ввиду? Конфликты при обновлении измененных баз клиентов?
Если да, то возможны несколько вариантов:
1) доработки для клиентов оформляются как доп. модули и включаются в типовую поставку — таким образом модифицированные под клиента конфигурации остаются «типовыми»;
2) для внедрения наших модулей в популярные типовые конфигурации планируется писать специальные модули интеграции — т.о. «спарки» с типовыми будут делаться по определённой понятной технологии, учитывающей необходимость последующих обновлений;
3) для прочих случаев рассматриваются варианты взаимодействия с 1С-ИжТиСи с их сервисами и технологиями обновления нетиповых конфигураций
спасибо автору, было интересно прочитать данную публикацию для повышения своего кругозора
почему не предусмотрена триальная версия и ее деинсталляция?
А так-же механизм отказа от модуля и деинсталяция оного. На мой взгляд главная проблема БСП — это невозможность отказа от того что уже установлено, вы идете по тому-же пути?
(5) TrinitronOTV,
Бот по зарабатыванию старт маней ??? Ваши ответы (не только в этой теме) однотипны, частенько не впопад, и не несут никакой конкретики.
(3) pumbaE,
+1
кстати на сколько я понял проект идет по принципу статической линковки, я не считаю этот путь реализуемый в принципе, я за динамическую линковку.
(7) vde69, ты думаешь он ответит тебе и заработает еще немного маней ? =))
(9) AllexSoft,
может модераторы заметят 🙂
(6) vde69, триальная версия предполагается только в режиме сервиса.
Отказ от любого модуля возможен в любое время — для этого его просто нужно отключить в настройках. Физически модуль никуда не исчезает, но для пользователей он становится «деинсталлирован».
(11)
>>>Физически модуль никуда не исчезает, но для пользователей он становится «деинсталлирован».
а как с объектами? мы опять имеем форму с 10000000 реквизитов 90% которых отключены по функциональным опциям? чем Ваша сборка формы м ее кеширование будет лучше БСП? А в коде будет мульен проверок типа Если Модуль1Подключен() Тогда ….
Если это так — то Вы опять наступаете на грабли БСП, и я Вас тогда не буду расматривать даже как теоретических конкурентов 🙂
(11)
Может лучше пересобрать конфигурацию с учетом только подключенных модулей?
(12), (13) — Пересборка конфигурации с учётом только подключенных модулей возможна. Я пока не очень понимаю зачем это может понадобиться клиенту и чем это лучше простого отключения неиспользуемого модуля, но потенциально это возможно.
(14) Вы сейчас делаете навязаный сервис, фиксики относятся к такому очень осторожно.
Я фиксик со стажем 15 лет и понимаю чего они хотят куда лучше чем франчи и сама 1с. Вы сейчас делаете систему «Под себя», ровно так-же как и 1с сделала БСП «под себя», а нужно «под фиксиков», по тому что именно специалисты на местах (не обязательно йс) будут принимать решения чем им пользоватся.
Безусловно Вы найдете клиентов, но продукт не будет популярным, так как реально не дает фиксикам возможности играть как в конструктор.
В моей концепции все повернуто именно в сторону фиксиков, для того что-бы им было удобно
1. выбирать и сравнивать функционал
2. переходить на новый функционал
3. допиливать
4. обновлять
5. ОТКАТЫВАТЬ ОБНОВЛЕНИЯ отдельных модулей (чего в 1с нет даже идеологически)
Как удобно фиксикам
делаем копию, накатываем новый модуль — даем пользователям, те смотрят и потом принимают решение.
если все нормально — идем покупать модуль
купили — проинсталировали и наблюдаем, в случае ЧП — откатили и модуль снесли, но данные за тестовый период должны остаться
Обновление — по подобной схеме, что бы можно было вернутся на старую «прошивку» в течении тестового периода.
Ладно пойду продавать свою модульную систему…
(14)
Например, для деинсталляции отдельных модулей и возможности установки альтернативных. Ведь модули при решении одинаковых задач могут иметь совершенно различную реализацию. Для гибкости было бы неплохо использовать оба варианта.
(15)
делаем копию, накатываем новый модуль — даем пользователям, те смотрят и потом принимают решение.
если все нормально — идем покупать модуль
купили — проинсталировали и наблюдаем, в случае ЧП — откатили и модуль снесли, но данные за тестовый период должны остаться
Это реальная потребность реальных людей? Включать/выключать туда-сюда. Вы знаете этих людей?
(18) zaebunga,
это нормальная практика для модульных систем.
Например банк имеет модульную систему в базовой поставке, и тут ему нужен модуль управления сделками REPO, он сначало тестирует, а потом запускает в ТЕСТОВОМ режиме модуль на рабочей, и только после прохождения тестового режима он оплачивает модуль…. или удаляет….
Да простой пример модуль CRM можно интегрировать в любую базу, но модуль CRM выпускают 5 разных компний, фиксики установливают по очереди все варианты пока не найдут тот который им понравится.
Или по твоему реальный выбор можно сделать по презентации ??? ты видел презентации франчей? там просто конфетки одни 🙂
(19) vde69, я не об этом спросил: конкретно вы видели конкретных людей, которым за каким-то хером надо включать/выключать модули с высокой скоростью? В решении на платформе 1С.
(18) zaebunga, реальная потребность дорабатывать сейчас без учета «сферической функциональной опции в вакууме», которая возможно через 2 года понадобится.
(19) vde69, при чем тут франчи? Продажники они и в африке продажники.
(21) pumbaE, я про людей спросил. Вы говорите про «потребность» — она чья? Кто этот человек, который модули туда-сюда мызгает?
(20) zaebunga,
разумеется видел, сколько я встречал компаний которые купили хрень, поигрались и потом не знают как снемти, и пользоваться не пользуются и проблеммы имеют
(23) vde69, получается такой алгоритм:
1. «купили хрень»
2. «поигрались»
3. «потом не знают как снемти»
И ради того, чтобы облегчить этим чудакам удаление куска конфигурации, надо мутить вот всю эту хрень, которая в теме обсуждается?
(24) zaebunga,
да ради этого и стоит делать модульность…
если Вы не понимаете какие при этом будут конкурентные приемущества — я Вас не смогу убедить.
открою секрет: делать новую систему нужно только если есть конкурентные приемущества, то есть все удачные нововедения имеют некую «фишку» для пользователя, если фишки нет — то нововедение естественным путем не приживется.
Взять того-же снегопата, у него есть то чего нет в 1с. А чего будет в сабже??? сервис который персонально Вам соберет конфу по весьма сомнительным «галочкам» которую Вы не сможете дорабатывать без франча?
(25) vde69,
Т.е. ради удовлетворения потребности фиксика в тычках мышью. Ну его нахер — принимать взвешенные решения.
Попробуйте, ради интереса — заодно выясним, где дыра в мировоззрении — у вас или у меня. Я выполню роль ИТ-директора завода. У меня УПП 1.3. Расскажите мне, нахера мне ваша модульность и что за модули хотите предложить.
Давайте лучше я вам секрет открою: в наших текущих условиях главная фишка — качество. Это то, чего не хватает больше всего. Качества решения, качества кейсов, качества сопровождения.
Не очень удачный пример. Ну есть там то, чего нет в 1С. Что это дает мне, как разработчику? Именно как разработчику, а не как тому чувырле, которого прикалывает модули включать/выключить.
(26) zaebunga,
Приходит зам директор к IT директору завода на котором стоит УПП 1.3 и говорит:
— Ваша служба просто за….. всех, поток жалоб не прекращается, пора всех вас разогнать
— Но прежде чем принять решение я сам хочу проверить как вы работаете, в течении месяца вам надлежит внедрить CRM, контактировать будете лично со мной, главное чего я хочу это видеть чем занимаются менеджеры все их контакры записи всех телефонных переговоров, всю почту, логи аськи и т.д. Все это должно быть в УПП и должно мне понравится.
— Руководитель потыкался и нашел сто CRM существует типовая в УТ-11, от Раруса, от БиТа и от своего знакомого Васи Пупкина.
Вот тут у руководителя и встает задача проанализировать все решения и выбрать то которое допиливать. При чем не на тестовых базах разработчиков а в реальной системе, начинаются игры с установкой на копии, хорошо, выбрали, показали — запустили…. Через 3 дня приходит Директор и говорит
— я вот слышал что то что у нас установлено (конфа 1) не поддерживает отправку смс, да и зашифруйте все контакты, ну ка доработайте… а в другой конфе (от конкурента) это реализовано….
я к чему это, да к тому что если есть альтернативные модули, то заменить один на другой — это офигительный плюс.
Еще пример
есть модуль РозничнаяТорговля и на его основании дополнение к нему «кассовый зал», вдруг ты выясняешь что конкуренты выпустили свой модуль РозничнаяТорговля совместимый с первым по интерфейсам но содержащий доп плюшки, по чему-бы просто не поменять модули???
(27) vde69, вы рассматриваете гипотетические примеры — на их основании убедить ИТ-Директора не получится.
Начиная с
Дальше.
1. У нас уже есть CRM от Раруса. Появился он ровно потому, что фиксик почитал интернет и захотел «потыкать» модули. Научил этот опыт в том числе и тому, что доверять стоит только разработкам 1С.
2. Переключаться между разными модулями разных поставщиков — больше похоже на бред. Хотя бы потому, что они на разных объектах МД работают.
(28) zaebunga,
если хотите конкретики — давайте конкретную Вашу проблемму, любой маркетинг начинается с осознанием потребителем проблеммы.
Если у Вас нет проблемм, то Вам не интересна ни какое новое начинание.
Впрочем Вы сами озвучили проблемму,
Если Вы директор IT — то озвученные проблеммы это ВАШИ проблеммы а не пользователей. Идем по порядку
1. Проблемма качества — частично решается путем деинсталяции версии модуля, выпустили косячную версию а косяу вылез только к закрытию месяца, указаный мною способ решает проблемму — откатываем версию назад и все…
2. Качество кейсов — сферический конь в вакууме, есть SLA и на основании его выделяем что именно не устраивает в работе с разработчиком модуля, если SLA не выполняется меняем поддержку на конкурента. Опят-же путем деинсталяциимодуля и заменой на модуль конкурента. Приведенная мною схема решает Вашу проблемму
3. качество сопроваждения — аналогично п.2
Мое решение позволяет решить озвученные Вами проблеммы почти полностью.
зы
но что-то мне не верится что Вы действительно Директор IT завода, уж извените, но по общению этого не видно. Скорее программист на заводе.
(28) zaebunga,
БИНГО!!!! вот вам и сабж, вам-же хочется поменять или вообще удалить CRM от раруса?
(29)
Так у меня нет проблем. Мы обсуждаем модульность — нахера она нужна и кому.
Из обсуждения с вами я сделал вывод, что главное назначение модульности — быстрое встраивание/удаление модуля. Вот эта часть и вызывает сомнение. Кому и зачем оно надо.
Я изначально это видел как систему для клиента, у которого нет ИТ-спецов. В этом есть теоретический смысл, но я хотел дождаться объявления списка модулей. Чтобы было понятно, что будем включать/выключать.
Вы же говорите про фиксу. Т.е. про программиста. У меня большие сомнения есть, что этому чуваку надо жизнь облегчать — по крайней мере, столь серьезными средствами, как модульность. И фиксе это, кстати, невыгодно — он с работы вылетит, т.к. клиент сам будет мышкой тыкать. Экономист, например — если будет также просто, как панели инструментов в экселе выводить.
P.S. Про CRM у нас — он совершенно не мешает, в т.ч. обновлениям. А удалять его — не по понятиям, деньги же уплачены.
(30) vde69, не хочется ни поменять, ни удалить.
Поменять не хочется, т.к. ничего стоящего нет.
Удалить не хочется, потому что не мешает, есть не просит и деньги заплачены. Потихоньку взлетает.
интересная статья,жаль нельзя это все попробывать на деле
(30) vde69, а мне вот ее выкинуть захотелось, как же так можно было писать то CRM, такое ощущение что писалось под какого то одного клиента, потом подумали что нужно бы сделать отраслевым решением и родилось ОНО. Вообще подобные CRM системы нужно делать с 0 (на БСП) под заказчика, мое ИМХО. Если знаете толковую МАШТАБИРУЕМУЮ CRM систему на 1с, то буду рад услышать рекомендацию.
я к чему это, да к тому что если есть альтернативные модули, то заменить один на другой — это офигительный плюс.
да отличный плюс, а то все запарились объединять чертыхаясь, даешь «заимствования» кода в промышленных масштабах. А вапще идея собирать конструктор в 1с — правильная конечно
(18) zaebunga,
Нет, не так. Включили, попробовали «ИТшники», попробовали/обкатали «юзвери» — выяснили, что данное решение не устраивает по набору параметров (в презентации одно, на практике другое; недореализовано и т.д.) и провели удаление.
Обычно для подобных целей можно создать отдельную базу, которую потом не жалко «грохнуть», и очень удобно было произвести удаление этого модуля. Но исходя из ранее описных механизмов (в других статьях), я могу предположить что такое в принципе будет не возможно. У меня возникло такое ощущение, что пользователь должен купить «монстра», который будет разрастаться (модули же добавляются — и модуль ли это в стандартном понятии…).
(36) ivanov660, это не то чтобы «ИТшники», скорее их отдельная часть — «дрочеры». Увы, таких много.
Так и осталось непонятным, правда, нахера городить такой огород с модульностью, чтобы дрочеров удовлетворить. Понятно, когда одни дрочеры других удовлетворяют — это «ромашка» называется 🙂 Но тут вроде толковые парни тусуются, но своими клиентами упорно видят дрочеров.
Как это в деньги будет переводиться то? Дрочер пойдет к собственнику и скажет «купите модульную систему, я буду в ней флажки надрачивать»?
Когда проект доминикана провалится, можно считать описанную теорию ошибкой или неспособностью её реализации по причине отсутствия соответствующих знаний?
(38) Допустим , шансов нет . Ну и что ? Зато интересно.
чего то примолкли доминиканцы, то ли затаились, то ли не кормят, то ли телки и текила победили их программерский дух )
(31) zaebunga,
Быстрое включение выключение модулей — это не самое главное преимущество.
Модульное приложение — это набор слабосвязанных компонентов, которые могут независимо развиваться и объединяться в единое целое с минимальными усилиями. Это значит, что за разработку каждого модуля может отвечать отдельная команда разработчиков. Обновление каждого модуля в меньшей степени вызовет необходимость изменять соседние компоненты за счет слабой связанности.
Все это в конечном итоге ведет к качеству: разграничение ответственности и более легкое тестирование в пределах модулей.
(41) Elisy, насчет качества соглашусь. И дело даже не в модульности, а в конкуренции — двигателе эволюции, мать его…
Главное тут, опять же, экосистема, как администратор конкуренции. Ну там, чтобы честная была ко всем пацанам, а не только к БИТовским.
Итого: модульная поставка — инструмент администрирования конкуренции. Чтобы у клиента не было трудностей с «реализацией конкурентной борьбы».
(38) DoctorRoza,
Рано еще хоронить Проект. Конечно, не секрет, что 75% всех стартапов неуспешные, но это не значит, что стартапами не нужно заниматься. 25% стартапов достигают значительного успеха. Проект Доминикана показал, что в мире 1С есть место инновациям и отличному от стандартного способу мышления.
(43) Elisy, надеюсь, что данный проект будет удачным! Единственное, что видится неприятным, так это тот пафос и напыщенность с которой он начался. Соглашусь, если скажете, что это только бизнес и иначе в РФ нельзя по определению. Только .. скромнее надо быть. Провалятся, все будут брызжать слюной и не только. А хочется, чтобы получилось все удачно!
(40) AllexSoft,
Неделя дождливой была. Не было настроения креативить. Сидели и тупо кодили. Нескольким коллегам пришлось продлевать визы, так как 2 разрешенных месяца были на исходе. За просрочку по местным законам полагается штраф за каждый день.
(43) Elisy,
Поддерживаю… По статистике только 10% инноваций имеют коммерческий успех. Не все меряется деньгами, по этому Доминикана в любом случае УЖЕ успешный проект. В любом случае приживутся жизнеспособные идеи. У меня идея модульности уже вторую неделю в голове крутится.
(41) Elisy,
Я бы разделил модули на три класса «Системные модули»,»Универсальные модули» и «Прикладные модули».
Задача системных модулей — обеспечить интерфейс между пользователем и прикладными модулями. Решить технические проблемы связанные с технологическими ограничениями выбранных платформ.
например:
Доступ к SOAP веб-сервисам;
Воронка продаж типовыми средствами 1С (без использования Html, .Net etc.)
Задача универсальных модулей — обеспечить механизм для решения задач, которые не зависят от специфики предприятия.
например: управление задачами или передача сообщений.
Задача прикладных модулей — решать конкретные задачи предприятия.
К примеру структура групп модулей может быть следующая:
1) Модули закупок
2) Модули продаж
3) Движение ТМЦ
4) Движение ДС
5) Обязательства по ТМЦ
6) Обязательства по ДС
7) Себестоимость
8) Финансовый учет
9) Планирование
10) Бюджетирование
и т.д.
В приципе, количество человек требуемых для разработки системных модулей будет зависеть от технической сложности проблем. На универсальные модули достаточно 2-х. На каждую группу модулей по 2 человека.
И 1 архитектор на всех. Желательно не программист, тогда результат работы команды будет в большей степени ориентирован на реального потребителя.
Вспоминая добрым словом Брукса «Мифический человеко-месяц» с его первым и вторым пилотом — каждая пара должна включать одного программиста и одного эксперта в предметной области.
Вот. где-то так.
(39) Ish_2,
Шансы, даже очень реальные. Есть большая вероятность вообще вывести системы управления предприятием на другой уровень. Так, что риски того стоят!
(44) DoctorRoza,
У меня другая сфера ответственности, поэтому комментировать «пафос» сложно. Каждый должен заниматься своим делом. Люди, которые организовали информационное освещение Проекта, имели определенную задумку, и эти люди — профессионалы своего дела с большим опытом работы.