На данный момент очень часто встречаются статьи о быстром внедрении и адаптации типовых решений. Меня как участника процесса внедрения продуктов 1С как со стороны заказчика, консалтинговых компаний и франчайзи 1С, всегда удивляли вопросы, которые мы не задаем и на которые мы пытаемся ответить заказчику.
Так, к сожалению, я не встречал вопросы и обсуждение "Стоимость владения продуктом на всем жизненном цикле и в разбивке по этапам жизненного цикла?", "Как посчитать эффективность внедрения исходя из затрат, потраченных на это внедрение?". Чаще вопросы "Почему так дорого и долго?", "Зачем нужно первичное обследование, и почему я должен платить за много букв, которые описывают, как у меня все плохо, хотя я это знаю?" и.т.д. и.т.п.
Последние проекты и обсуждения сообщества показывают, что пришло время менять концепцию внедрения и адаптации типовых решений.
Так как программирование на 1С это мое хобби в свободное время, буду приводить, возможно, примитивные решения с точки зрения разработки, но в тоже время хочу кинуть "камень" с вопросом, "а студент колледжа может быть участником качественного внедрения со стороны разработки?". Много кода для начинающих я выкладывал в своем блоге в свободном доступе, так как то, что я уже сделал сегодня, а завтра будет уже совсем иначе ).
Пример простой "Склад" в УНФ, УТ 11.5. Тут не полное, конечно, описание, а кусочки большой мозаики.
Задаем заказчику вопрос "Кто и что делает у Вас на складе", ну нам же нужна ролевая модель. Ответ типовой: у нас нет разделения и.т.д. и.т.п. Вопрос "А кто материально ответственный" начинает вводить в ступор тех, кто хочет прям все из коробки.
Все прототипы сделаны в расширении и с применением дополнительный реквизитов. Ниже буду приводить пример части кода и скрины с действующих систем.
Для ролевой принимаю решение использовать типовую возможность 1С, которая позволит на основе предыдущего опыта быстро, но с правами администратора разделить доступ. Использую режим "основного окна", назначим нашу обработку начальной страницей.
Далее определим, для каких ролей этот режим использовать. Функция универсальна для любых решений
Результат:
Кладовщик
Комплектовщик
Итак, первая задача решена. Добавлю, что из формы нельзя переходить в справочники, документы и.т.д.
Как и ранее писал, в первом варианте не устраивал дизайн и мелкие недочеты, поэтому следующее решение построить форму АРМ так, чтобы нумерация "Руководства эксплуатации" , "Технического задания", и.т.д. и визуализации АРМ совпадали. Примерно так
Технически это так. Дерево значений с любой глубиной, которую определили. При этом меню я делю на вертикальное, это дерево значений и переключатель на странице горизонтальное меню. Но работают все с одной таблицей значений. Ниже таблица значений и варианты дерева.
Для пользователя системы это выглядит так:
В силу универсальности процедур формирования меню АРМ перенос в любую систему, это подключение моего расширения.
Сразу оговариваемся, что процедуры и функции, которые используют объекты типовой системы, нам придется адаптировать. Но и тут я для себя нашел решение быстрой адаптации, но об этом ниже.
В первых версиях прототипа меня не устроила перегруженность интерфейса и непонятность последовательности действий без чтения инструкции, а это все доп. расходы времени на обучение и адаптацию персонала. Поэтому в последних решениях у меня три панели, тут не открываю какой-то секрет, так вскользь во многих статьях видел описание такого решения. Слева панель меню -сворачиваем автоматом через минуту или вручную, справа панель доп. отборов и информации (кнопка свернуть внизу - как в УНФ), центр рабочее поле. (Для скринов, роль Администратора).
Теперь приведу пример решения одной частности которая облегчила жизнь кладовщика. При выборе заказа можем использовать кнопку или Drag-and-drop (заказ переносим в правую таблицу и отражаем позиции заказа). В табличной части взятой в работу номенклатуры (правая таблица) отражаем только не принятые или частично принятые позиции (частичная поставка). Работать можно одновременно по нескольким поступлениям, на каждое поступление автоматически создаем документ ПТУ и счет-фактуру.
В части заполнения сроков годности и хранения в ячейках без использования дополнительных документов. В табличной части по номенклатуре (в левой части таблица номенклатуры, в правой связанная табличная часть серии и ячейки, которая позволяет реализовать один ко многим), в которой ведется учет по срокам годности, при заполнении даты производства автоматически заполняем срок годности, производим выбор ячейки хранения (тут автоматизация имеет развитие, но первично для демонстрации вручную). Если срок хранения разный то строка разбивается автоматически, при изменении количества в строке.
Отчеты, как и печатные формы, открываем так же в АРМ без открытия доп. окон.
При нажатии на закрытие окна печати возврат в список заказов.
Таким образом реализована концепция одного окна.
Техническая часть
Проблема в 1С - иногда поля разных формах имеют имя разное, хотя могут использовать один и тот же источник данных, ну и понятно, что УНФ и УТ или ERP и.т.д. и.т.п как разные вселенные не только в разности их применения. Тут большая работа аналитиков, понимать и сравнить эти решения, для себя решил, что это уровень объектов системы, а не только документов в бизнес-процессе. Тем более в этом нет каких то трудностей.
Конечно, если эти сравнения еще выкладывать в интернет, то если это сравнение как БитФинанс и УХ, будет интересно многим. Лет 5 назад проделал такую провокацию, и выложил поверхностное сравнение сначала на корп. сайте, но как только по пожеланию наших партнеров ее убрали, то выложил в своем блоге. Это принципиальная моя позиция, если ваше решение настолько серьезно, чего Вам бояться мнения какого-то аналитика.
Сравнение на уровне объектов, тут как бы не нарушить авторского права. Но замечу, что стараюсь этого избегать. Приведу небольшой кусочек в виде скрина такого сравнения MDM - УНФ - ERP, думаю, для тех, кто в теме, будет понятно, что за справочник.
Таким образом надо было решить проблему - источники данных для реквизитов формы, и возможность быстро заменить часть кода, к примеру, в части программного создания документов, запросов ...
Подглядел и реализовал для программного создания документов следующее:
Эта функция, которая возвращает поля и путь к данным для обязательного заполнения и возможности проведения документа
Процедуры и функции универсальны, мы видим, нам нужно указать, какой документ создать и указать в функции поля для заполнения.
Запросы для динамических списков переопределяемые, нам останется только заменить запрос при адаптации.
Реквизиты - очень удобно использовать Определяемые типы. Что позволит изменить сразу во многих местах исправив в одном месте.
Но приведу цитату с ИТС 1С - "Некорректно использовать определяемые типы для задания «синонима» существующему типу, «подмены» сущностей, для локального (не массового) использования в рамках одной подсистемы (конфигурации) без необходимости внедрения в другие конфигурации, только из соображений легкости доработки. Как правило, это говорит об ошибке проектирования или о методологически неверном выборе исходного имени типа"
Такие принципы позволят в короткое время адаптировать наше решение под выбранную систему, и уже плюс-минус через неделю продолжить разговор с потенциальным заказчиком уже предметно. Даже если показать два - три документа, которые будут созданы из АРМ, заказчик явно остановит свой выбор на Вас. А копи паст подход не заставит ждать заказчику, когда новая система будет внедрена. При этом приятный бонус это наличие всей документации, независимость от команды (описание позволит просто воспринимать чужой код, суть бизнес процесса)
Возвращаясь к началу , мы имеем расходы на внедрение, которые можем снижать с каждым последующим внедрением. Заказчику мы можем продать документацию или поменять на сопровождение. Тогда очевидно выстроится стоимость владения продуктом.
Возможно, такой подход не будет работать на крупных проектах, но на мало бюджетных это возможность обойтись малой "кровью".
