Комментарии 24
Мои SAP-консультанты прочитав вашу статью про «модульные» системы усмехнулись и сказали всего одно слово — «бред». Сам я внедряю SAP всего на 2 проекте и то, в качестве РП, поэтому просто спрошу — сколько внедренных проектов у вас за спиной? У меня лично, после 5 внедрений (примерно по 1-2 года на проект) есть четкое понимание — что абсолютно не важно, какую ты систему внедряешь. Успешность внедрения и дальнейшей работы примерно на 20% зависит от используемой системы (будь то SAP, 1С или система написанная на C#).
Саповские консультанты настолько суровы, что всего лишь снисходительной усмешкой и лапидарным «бред» способны опровергнуть любую сколь угодно прочно обоснованную позицию.
С другой стороны, а что им еще остается? Для повышения настроения ваших коллег рекомендуем еще пару ссылочек: www.ultimaerp.com/compare/sap/, www.ultimaerp.com/library/sap300/.
Касательно тезиса, что «абсолютно неважно, какую систему ты внедряешь» — экспрессивность и глубокомысленность сообщения намекает, что спорить с ним не следует. Тем более, что у нас такой задачи и нет и тем более, что в приведенных ссылках на эту тему, в общем, все сказано.
Количество наших внедрений не имеет логической связи ни с комментируемым вами текстом, ни с любым другим опубликованным здесь или у нас на сайте. Переменная Х, содержащая количество внедрений продуктов компании Ultima, в аргументации нигде не участвует. Хотя их, безусловно, несколько больше пяти.
P.S. Что-то вдруг вспомнилось из Жванецкого:
«Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера.
Что может говорить хромой об искусстве Герберта фон Караяна? Если ему сразу заявить, что он хромой, он признает себя побежденным.
О чем может спорить человек, который не поменял паспорт? Какие взгляды на архитектуру может высказать мужчина без прописки? Пойманный с поличным, он сознается и признает себя побежденным.
И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется.»
С другой стороны, а что им еще остается? Для повышения настроения ваших коллег рекомендуем еще пару ссылочек: www.ultimaerp.com/compare/sap/, www.ultimaerp.com/library/sap300/.
Касательно тезиса, что «абсолютно неважно, какую систему ты внедряешь» — экспрессивность и глубокомысленность сообщения намекает, что спорить с ним не следует. Тем более, что у нас такой задачи и нет и тем более, что в приведенных ссылках на эту тему, в общем, все сказано.
Количество наших внедрений не имеет логической связи ни с комментируемым вами текстом, ни с любым другим опубликованным здесь или у нас на сайте. Переменная Х, содержащая количество внедрений продуктов компании Ultima, в аргументации нигде не участвует. Хотя их, безусловно, несколько больше пяти.
P.S. Что-то вдруг вспомнилось из Жванецкого:
«Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера.
Что может говорить хромой об искусстве Герберта фон Караяна? Если ему сразу заявить, что он хромой, он признает себя побежденным.
О чем может спорить человек, который не поменял паспорт? Какие взгляды на архитектуру может высказать мужчина без прописки? Пойманный с поличным, он сознается и признает себя побежденным.
И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется.»
Я правильно понял, что у вас под каждого клиента по сути написана отдельная программа, и у программ одинаковое ядро?
А чем Ваши бизнескейсы отличаются от модулей?
Тем, что они не модули.
А можно систему чтобы она покрывала несколько бизнес кейсов?
Не понял вопрос. Что за система имеется ввиду?
Все-таки попробую ответить на вопрос. Если я правильно понял, то его можно сформулировать как «Возможно ли совмещение функционала нескольких кейсов в рамках одного решения?».
Ответ на него — да. Функционал любого количества (необходимых) кейсов, пусть даже работающих в нескольких различных проектах переносится в новое решение у конкретного клиента.
Надо понимать, что система у нас монолитная, и переносимый функционал это не модуль в каком-либо виде. На всякий случай напомню, что кейс — это совокупность процессных, управленческих и технических решений.
Ответ на него — да. Функционал любого количества (необходимых) кейсов, пусть даже работающих в нескольких различных проектах переносится в новое решение у конкретного клиента.
Надо понимать, что система у нас монолитная, и переносимый функционал это не модуль в каком-либо виде. На всякий случай напомню, что кейс — это совокупность процессных, управленческих и технических решений.
Прочитав вашу статью про модульные системы, сразу понял что они лучше :) Особенно понравилась аналогия с оутсорсингом подразделений — идеальный вариант бизнес процессов.
Любопытно. Я архитектор и мы, вместе с командой разработчиков, пишем учетные системы внутри крупного финансового холдинга. А можно вопросов по задавать?
1. На чем пишут прикладные разработчики? (IDE и язык программирования).
2. Почитал про модульность и до конца не понял.
Что можно сделать в модуле? Можно и насколько широко можно его повторно использовать?
2.1 Вот могу я сделать модуль, например, который будет искать дубли в справочниках и удалять их с сохранением ссылочной целостности? Но так, чтобы потом этот модуль можно было использовать без доработок во всех решениях?
2.2 Могу ли я выпустить обновление своего модуля? Могут ли клиенты обновить в своем решении только мой модуль и ничего больше?
3. Как происходит выпуск обновлений? Могу ли я с обновлением поставлять данные?
Например, поставил я справочник. Далее пользователь вносит в него изменения (добавляя, редактируя и изменяя данные).
Теперь в очередном обновлении я также поставляю справочник с изменениями. Как мои изменения будут сливаться с изменениями пользователей?
4. Что в системе из следующего списка можно сделать на боевом проекте аналитику без привлечения программиста:
4.1 Подредактировать форму документа?
4.2 Настроить состав и порядок колонок в таблице справочника для всех пользователей?
4.3 Для пары полей «сотрудник» / «проект» добавить в форме проверку, что выбранный сотрудник входит в ранее выбранный проект.
1. На чем пишут прикладные разработчики? (IDE и язык программирования).
2. Почитал про модульность и до конца не понял.
Что можно сделать в модуле? Можно и насколько широко можно его повторно использовать?
2.1 Вот могу я сделать модуль, например, который будет искать дубли в справочниках и удалять их с сохранением ссылочной целостности? Но так, чтобы потом этот модуль можно было использовать без доработок во всех решениях?
2.2 Могу ли я выпустить обновление своего модуля? Могут ли клиенты обновить в своем решении только мой модуль и ничего больше?
3. Как происходит выпуск обновлений? Могу ли я с обновлением поставлять данные?
Например, поставил я справочник. Далее пользователь вносит в него изменения (добавляя, редактируя и изменяя данные).
Теперь в очередном обновлении я также поставляю справочник с изменениями. Как мои изменения будут сливаться с изменениями пользователей?
4. Что в системе из следующего списка можно сделать на боевом проекте аналитику без привлечения программиста:
4.1 Подредактировать форму документа?
4.2 Настроить состав и порядок колонок в таблице справочника для всех пользователей?
4.3 Для пары полей «сотрудник» / «проект» добавить в форме проверку, что выбранный сотрудник входит в ранее выбранный проект.
1. C# как язык. Для рисования форм VisualStudio. Для описания бизнеслогики своя IDE
2. Наша система как раз скорее монолит. Т.е. понятия модуль как фалик с функционалом — нет.
Как следствие, нет выпуска обновлений — система всегда заточена под заказчика.
4. Начать надо с того что аналитик занимается анализом задачи, ее проектирует решение внедряет его. Указанные действия не работа аналитика, однако да, он может поменять форму и настроить колонки. Последнее не понял если честно, но думаю, что нет.
Подробнее есть на сайте платформы.
2. Наша система как раз скорее монолит. Т.е. понятия модуль как фалик с функционалом — нет.
Как следствие, нет выпуска обновлений — система всегда заточена под заказчика.
4. Начать надо с того что аналитик занимается анализом задачи, ее проектирует решение внедряет его. Указанные действия не работа аналитика, однако да, он может поменять форму и настроить колонки. Последнее не понял если честно, но думаю, что нет.
Подробнее есть на сайте платформы.
Еще раз прочитал ответ, и понял, что в нем осталась двусмысленность. Попробую ее устранить.
1. C# как язык для описания бизнес-объектов, бизнеслогики и реализации всех прочих функций… Для рисования форм VisualStudio. Для описания бизнеслогики своя IDE с UI для описания бизнес-объектов (из которого генерятся соответствующие классы).
2. Система не модульная, а монолитная. Нет в ней модулей в виде отдельных файлов, программ или чего-либо еще. Кейс не модуль, это совокупность процессных, управленческих и технических решений. Да, в системе можно найти какие технические решения относятся к тому или иному кейсу, но это не модуль который можно перенести из одного проекта в другой копированием файлика или сходной операцией.
3. Обновления выходят для платформы и базового решения согласно графику.
В работающем решении можно обновить только платформу.
Обновления базового решения актуальны только для новых внедрений. Каждое решение для конкретного клиента — кастомизированный инструмент извлечения прибыли. Его изменения обусловлены не выходом новых версий базового решения, а только лишь изменением внешних или внутренних условий ведения бизнеса данного конкретного клиента.
Приведенный Вами пример — как раз ситуация не имеющая общего решения.
Еще добавлю пряму ссылку на описание архитектуры системы.
П. 4 вроде не может вызвать разночтений,
1. C# как язык для описания бизнес-объектов, бизнеслогики и реализации всех прочих функций… Для рисования форм VisualStudio. Для описания бизнеслогики своя IDE с UI для описания бизнес-объектов (из которого генерятся соответствующие классы).
2. Система не модульная, а монолитная. Нет в ней модулей в виде отдельных файлов, программ или чего-либо еще. Кейс не модуль, это совокупность процессных, управленческих и технических решений. Да, в системе можно найти какие технические решения относятся к тому или иному кейсу, но это не модуль который можно перенести из одного проекта в другой копированием файлика или сходной операцией.
3. Обновления выходят для платформы и базового решения согласно графику.
В работающем решении можно обновить только платформу.
Обновления базового решения актуальны только для новых внедрений. Каждое решение для конкретного клиента — кастомизированный инструмент извлечения прибыли. Его изменения обусловлены не выходом новых версий базового решения, а только лишь изменением внешних или внутренних условий ведения бизнеса данного конкретного клиента.
Приведенный Вами пример — как раз ситуация не имеющая общего решения.
Еще добавлю пряму ссылку на описание архитектуры системы.
П. 4 вроде не может вызвать разночтений,
Спасибо за ответы! Из Ваших ответов, мне кажется, я понял, где есть интересная тема дискуссии.
На мой взгляд, один из факторов, отличающий ERP системы от, например GameDevelopment в требовании частых выпусков обновлений. Т.е. изменился процесс (например, добавили\изменили атрибуты учета товара) — изменилась система. Скорее даже наоборот, пока не изменилась система не изменился процесс.
При этом еще есть важный нюанс, ERP это софт с большим сроком поддержки кода, лет 10-15. Т.е. нужно быстро выпустить код, но потом его 10 лет поддерживать уже другой командой.
Кстати, разделяете ли Вы эти обе позиции?
По этому мне очень интересно узнать, какие достоинства у Вас есть с точки зрения обновления системы для:
1. разработчика базового решения
Например:
невысокие требования к прикладным разработчикам решения (все разработчики за 10 лет поменяются трижды),
богатый инструментарий мигрирования модели и данных (добавили новое поле, старое удалили, данные по алгоритмы мигрировали)
легкость автоматического тестирования (наличие тысячи тестов позволит сократить время выпуска версии, но если тесты писать сложно или невозможно, то этого преимущества не будет).
2. для аналитика
Например:
легкость развертывания конфигурация для тестирования (как сложно получить собственную копию боевой системы но с последними, еще не выпущенными доработками).
какие из действий, которые в других системах требуют вмешательства разработчиков, у Вас могут выполнятся аналитиками (например, в форме добавить фильтр на ссылочное поле «Сотрудник», так, чтобы можно было выбрать только сотрудников определенного отдела, ну или еще что нибудь?)
3. для бизнес пользователя
мердж данных, поставляемых из решения с пользовательскими.
Например: в классификатор товаров добавили и заполнили новую колонку с кодом соответствия другого классификатора, плюс изменили три значения. Я хочу, чтобы мои ранее сделанные изменения других 10 записей были сохранены.
Такой мердж, мне кажется, типовая задача. Хочется, чтобы аналитик без разработчика просто открыл копию системы, исправил классификатор так, как он должен выглядеть и сохранил. А при выпуске обновления данные сами смерджились на боевой системе в тех случаях, где нет коллизий в изменениях. При этом, хочется перед выпуском версии легко проверить, будут ли такие коллизии или нет, чтобы только тогда при необходимости привлечь разработчика для исправлений.
И так, что интересного у Вас есть для подготовки и выпуска обновлений?
На мой взгляд, один из факторов, отличающий ERP системы от, например GameDevelopment в требовании частых выпусков обновлений. Т.е. изменился процесс (например, добавили\изменили атрибуты учета товара) — изменилась система. Скорее даже наоборот, пока не изменилась система не изменился процесс.
При этом еще есть важный нюанс, ERP это софт с большим сроком поддержки кода, лет 10-15. Т.е. нужно быстро выпустить код, но потом его 10 лет поддерживать уже другой командой.
Кстати, разделяете ли Вы эти обе позиции?
По этому мне очень интересно узнать, какие достоинства у Вас есть с точки зрения обновления системы для:
1. разработчика базового решения
Например:
невысокие требования к прикладным разработчикам решения (все разработчики за 10 лет поменяются трижды),
богатый инструментарий мигрирования модели и данных (добавили новое поле, старое удалили, данные по алгоритмы мигрировали)
легкость автоматического тестирования (наличие тысячи тестов позволит сократить время выпуска версии, но если тесты писать сложно или невозможно, то этого преимущества не будет).
2. для аналитика
Например:
легкость развертывания конфигурация для тестирования (как сложно получить собственную копию боевой системы но с последними, еще не выпущенными доработками).
какие из действий, которые в других системах требуют вмешательства разработчиков, у Вас могут выполнятся аналитиками (например, в форме добавить фильтр на ссылочное поле «Сотрудник», так, чтобы можно было выбрать только сотрудников определенного отдела, ну или еще что нибудь?)
3. для бизнес пользователя
мердж данных, поставляемых из решения с пользовательскими.
Например: в классификатор товаров добавили и заполнили новую колонку с кодом соответствия другого классификатора, плюс изменили три значения. Я хочу, чтобы мои ранее сделанные изменения других 10 записей были сохранены.
Такой мердж, мне кажется, типовая задача. Хочется, чтобы аналитик без разработчика просто открыл копию системы, исправил классификатор так, как он должен выглядеть и сохранил. А при выпуске обновления данные сами смерджились на боевой системе в тех случаях, где нет коллизий в изменениях. При этом, хочется перед выпуском версии легко проверить, будут ли такие коллизии или нет, чтобы только тогда при необходимости привлечь разработчика для исправлений.
И так, что интересного у Вас есть для подготовки и выпуска обновлений?
Ух сколько!
Итак, по порядку.
Совершенно верно — ERP система (или более широко — система автоматизации предприятия) это система с частыми изменениями, очень длинным жизненным циклом и очень высокой стоимостью ошибки (система обрабатывает реальные деньги). Не могу назвать какие-ибо другие системы где указанные особенности присутствовали бы одновременно. В GameDev существуют системы с длинным циклом и высокой стоимостью ошибки, World of Warcraft или World of Tanks — они существуют уже долго, в них обрабатываются реальные деньги, но обновления — раз в год. В ERP системах изменения происходят ежедневно.
По Вашим вопросам.
1. Что есть для разработчика базового решения с точки зрения обновления системы
1.1. Разработка в боевой базе и использование редакций схемы БД. Как следствие:
— нет(и не надо) механизмов миграции данных
— запросы проверяются на реальных данных
1.2. Механизмы истории изменений решений и поиск авторов
1.3. Встроенные механизмы распределенной системы контроля версий
1.4. Модель с высоким уровнем абстракции
1.5. Отметка любых объектов решения тегами и поиск по ним
1.6. Тесты логики (и интеграция с TeamCity, возможна интеграция с подобными системами)
Насчет легкости их написания затрудняюсь ответить. Высокий уровень абстракции позволяет проверять правильность по нескольким параметрам (например после сохранения документа мне важно, чтобы он сгененрировал правильные проводки). Возможно, там пока еще есть непаханное поле.
2. Для аналитика. Благодаря встроенной системе контроля версий аналитик работает с «Тестовой» версией решения глядя на реальные данные.
Разработку «аналитиком» мы не приветствуем. Думаю в этом плане мы не отличаемся от других систем. Аналитик как разработчик может в рантайме менять все что угодно, за исключением кастомных экраных форм (требуется студия)
3. Для бизнеспользователя.
Повторюсь, мы проповедуем работу с реальным данными в разных версиях схемы БД. Поэтому нет таких операций, как мердж данных.
В приведенном Вами примере с новой колонкой, данные будут залиты в колонку разработчиком, и станут видны аналитикам (и потом пользователям) после переключения на версию, в метаданных которой эта колонка описана. Сама колонка физически с данными будет так же присутствовать. Для новых записей будет вычислятся значение по умолчанию (легко заметить, что это всегда возможно, когда возможен мердж пользовательских данных).
Вообще редакция схемы (точное название Schema edition) очень удобная функция. Фактически существует несколько версий View для просмотра данных и, соответственно, триггеров на Insert и Update. Схема определяется в момент подключения к БД.
Итак, по порядку.
Совершенно верно — ERP система (или более широко — система автоматизации предприятия) это система с частыми изменениями, очень длинным жизненным циклом и очень высокой стоимостью ошибки (система обрабатывает реальные деньги). Не могу назвать какие-ибо другие системы где указанные особенности присутствовали бы одновременно. В GameDev существуют системы с длинным циклом и высокой стоимостью ошибки, World of Warcraft или World of Tanks — они существуют уже долго, в них обрабатываются реальные деньги, но обновления — раз в год. В ERP системах изменения происходят ежедневно.
По Вашим вопросам.
1. Что есть для разработчика базового решения с точки зрения обновления системы
1.1. Разработка в боевой базе и использование редакций схемы БД. Как следствие:
— нет(и не надо) механизмов миграции данных
— запросы проверяются на реальных данных
1.2. Механизмы истории изменений решений и поиск авторов
1.3. Встроенные механизмы распределенной системы контроля версий
1.4. Модель с высоким уровнем абстракции
1.5. Отметка любых объектов решения тегами и поиск по ним
1.6. Тесты логики (и интеграция с TeamCity, возможна интеграция с подобными системами)
Насчет легкости их написания затрудняюсь ответить. Высокий уровень абстракции позволяет проверять правильность по нескольким параметрам (например после сохранения документа мне важно, чтобы он сгененрировал правильные проводки). Возможно, там пока еще есть непаханное поле.
2. Для аналитика. Благодаря встроенной системе контроля версий аналитик работает с «Тестовой» версией решения глядя на реальные данные.
Разработку «аналитиком» мы не приветствуем. Думаю в этом плане мы не отличаемся от других систем. Аналитик как разработчик может в рантайме менять все что угодно, за исключением кастомных экраных форм (требуется студия)
3. Для бизнеспользователя.
Повторюсь, мы проповедуем работу с реальным данными в разных версиях схемы БД. Поэтому нет таких операций, как мердж данных.
В приведенном Вами примере с новой колонкой, данные будут залиты в колонку разработчиком, и станут видны аналитикам (и потом пользователям) после переключения на версию, в метаданных которой эта колонка описана. Сама колонка физически с данными будет так же присутствовать. Для новых записей будет вычислятся значение по умолчанию (легко заметить, что это всегда возможно, когда возможен мердж пользовательских данных).
Вообще редакция схемы (точное название Schema edition) очень удобная функция. Фактически существует несколько версий View для просмотра данных и, соответственно, триггеров на Insert и Update. Схема определяется в момент подключения к БД.
Ага, Вас понял. Действительно, если на боевой вести разработку, то значительная часть проблем с поставкой — уходит.
Интересно, что у меня всю жизнь было (и есть) строго противоположное мнение: «после поставки решения на боевую систему у разработки не должно к нему быть доступа.» Возможности разработчика очень велики, и, мне кажется, сделать внутреннюю защиту от падения всей системы после исправления кода — очень сложно (невозможно).
Еще, мне кажется, в этом случае очень сложно детерминировать систему. Т.е. когда возникает плавающий баг или лаг, то когда его источник не очевиден возникает соблазн начать спрашивать всех разработчиков с пристрастием о том, кто что делал недавно на боевой системе.
И, мне кажется, подход «работаем на боевой» подходит только когда у вас ровно одна система. Т.е. когда вы автоматизируете свою компанию а не пишите код для 100 клиентов. У вас же нет боевых данных клиентов и вы не сможете зайти во все 100 систем и поправить руками данные справочника вместо централизованной поставки данных.
Или Вы нашли для последней проблемы какое то решение? Если да, то очень интересно, какое?
Интересно, что у меня всю жизнь было (и есть) строго противоположное мнение: «после поставки решения на боевую систему у разработки не должно к нему быть доступа.» Возможности разработчика очень велики, и, мне кажется, сделать внутреннюю защиту от падения всей системы после исправления кода — очень сложно (невозможно).
Еще, мне кажется, в этом случае очень сложно детерминировать систему. Т.е. когда возникает плавающий баг или лаг, то когда его источник не очевиден возникает соблазн начать спрашивать всех разработчиков с пристрастием о том, кто что делал недавно на боевой системе.
И, мне кажется, подход «работаем на боевой» подходит только когда у вас ровно одна система. Т.е. когда вы автоматизируете свою компанию а не пишите код для 100 клиентов. У вас же нет боевых данных клиентов и вы не сможете зайти во все 100 систем и поправить руками данные справочника вместо централизованной поставки данных.
Или Вы нашли для последней проблемы какое то решение? Если да, то очень интересно, какое?
В данном случае приходится выбирать некоторый баланс между производительностью системы, легкостью поддержки, скорости доставки изменений, стабильности и доступности данных.
Все изменения кода логируются, устраивать допрос не требуется.
Об этом я попытался рассказать в своей статье про систему версионирования.
Напомню, что каждый отдельный проект это заточенная под конкретного клиента система. Так что изменения у всех уникальные. Не возникало пока ситуаций что требуется зайти ко всем клиентам и сделать какие-либо одинаковые изменения.
Все изменения кода логируются, устраивать допрос не требуется.
Об этом я попытался рассказать в своей статье про систему версионирования.
Напомню, что каждый отдельный проект это заточенная под конкретного клиента система. Так что изменения у всех уникальные. Не возникало пока ситуаций что требуется зайти ко всем клиентам и сделать какие-либо одинаковые изменения.
Я занимаюсь внедрением и сопровождением 1с 15 лет. И точка зрения автора этой статьи полностью коррелирует с выстраданным опытом.
Монолитность ERP рулит. У 1С местами появляются намеки на модульность и это всегда приводит к проблемам в виде несогласованности данных. В ряде случаев получал отзывы от клиентов, что создание единой НСИ на предприятии давало реальные положительные эффекты. Если каждый отдел пользуется своим модулем это не ERP. ERP возникает, когда данные, введенные одной службой, тут же используются другой.
Минимальное ядро конфигурации это круто. Давно мечтаю. Очень жаль что 1С не поставляет свои решения в таком виде. Хотя их можно понять: когда клиент покупает программу, он читает перечень фич. А то что половина фич прямо из коробки идет в ведро, и пишется заново, выясняется потом. Или не выясняется.
Монолитность ERP рулит. У 1С местами появляются намеки на модульность и это всегда приводит к проблемам в виде несогласованности данных. В ряде случаев получал отзывы от клиентов, что создание единой НСИ на предприятии давало реальные положительные эффекты. Если каждый отдел пользуется своим модулем это не ERP. ERP возникает, когда данные, введенные одной службой, тут же используются другой.
Минимальное ядро конфигурации это круто. Давно мечтаю. Очень жаль что 1С не поставляет свои решения в таком виде. Хотя их можно понять: когда клиент покупает программу, он читает перечень фич. А то что половина фич прямо из коробки идет в ведро, и пишется заново, выясняется потом. Или не выясняется.
Т.е. правильно ли я понял, общий код копируется из проекта в проект? Как вы тогда решаете проблемы поддержки общего кода в 100 решениях? И как решают проблему Ваши партнеры, если у них нет доступа к исходному коду (или все партнеры сами собирают решение из исходников?).
Не совсем. Общий код не копируется из проекта в проект. Он(код) существует в виде «базового решения», которое поддерживается соответствующей группой разработчиков в партнерском центре. На каждый новый проект внедряющий партнер берет это базовое решение и дополняет его кейсами или специфическими доработками. После внедрения получается монолитная система, не предусматривающая обновлений прикладной части (платформа инвариантна, и может обновляться). Нет такого процесса, как обновление «базового функционала». Если бизнесу требуется какая-либо функциональность, она всегда имеет какие-то бизнес-цели. Всегда требуется не только изменение программы, но и процессов предприятия. Если бизнесу нужна функция — она реализуется тем или иным способом.
По второй части. Внедряющий партнер имеет доступ ко всем исходным текстам прикладной части (в том числе и базового решения) и волен их менять по своему разумению. Так же, партнеры имеют доступ к части исходного кода платформы для ознакомительных целей. Собирать из исходников требуется только кастомные экранные формы.
Впрочем, мы думаем над тем, чтобы избавится и от этого.
По второй части. Внедряющий партнер имеет доступ ко всем исходным текстам прикладной части (в том числе и базового решения) и волен их менять по своему разумению. Так же, партнеры имеют доступ к части исходного кода платформы для ознакомительных целей. Собирать из исходников требуется только кастомные экранные формы.
Впрочем, мы думаем над тем, чтобы избавится и от этого.
Но наверняка в базовом функционале время от времени находятся баги, которые касаются существенной части заказчиков. Что делается с ними? Бьёте в колокола и отправляете партнёров закрывать амбразуры, оставляете всё на откуп партнёра, или ждёте пока заказчик не обратиться «а у меня тут странное»?
С базовой конфигурации работает буквально несколько человек. С решениями у клиентов (суммарно) тысячи. Так что о баге нам сообщит партнер (как правило и со своим вариантом решения). Баг будет исправлен. Если баг может иметь место в других решениях то уведомляем партнеров о баге и рекомендуемом способе его исправления. Реально очень редкая ситуация, чтобы баг в базовой конфигурации всплыл после внедрения. Могу вспомнить буквально только 2 таких случая и оба они не баги даже, а проблемы производительности.
это 1с то монолит?
1с Бухгалтерия
1с УПП
1с Кадры и зарплата
1с Торговля
Продолжать?
1с Бухгалтерия
1с УПП
1с Кадры и зарплата
1с Торговля
Продолжать?
Долго лазил по вашим сайтам, но так и не понял, где внедрения ))
Можно ссылочку на завершенные проекты?
Можно ссылочку на завершенные проекты?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Буриданов осел и композиция конфигурации