Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

26.10.23

Программная инженерия - Работа с требованиями

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

Меня зовут Гюльнара Антропова, и я хочу рассказать про технологию автоматизации, которую мы используем в наших проектах.

В своем докладе я приведу только практический опыт. Я его проанализировала, обобщила и сформулировала в виде технологии. Возможно, вам будет интересно про нее узнать.

 

Представлюсь, почему я могу заявлять про какую-то авторскую технологию.

  • В проектах автоматизации 1С я с 1996 года – у меня есть опыт работы бизнес-аналитиком и во франчайзи, и со стороны заказчика, и в качестве независимого эксперта.

  • Есть опыт автоматизации типовых конфигураций без единой доработки.

  • Есть опыт автоматизации с внесением существенных изменений в типовые конфигурации.

  • Есть опыт, про который я вам сейчас хочу рассказать – когда мы не меняем типовую конфигурацию, но выполняем 98% противоречащих друг другу требований заказчика.

  • В 2014 году я основала школу скорочтения – казалось бы, как могут быть связаны школа скорочтения и 1С? В этот период времени я очень хорошо поняла, как мозг обрабатывает новую информацию. И эти продвинутые техники работы с информацией легли в основу той технологии, о которой я вам хочу рассказать.

  • В 2017 году у меня был очень значимый проект в Газпроме Республики Башкортостан. Там под моим руководством и при моем участии была с нуля разработана автоматизированная система управления имуществом. Чтобы вы понимали, имущество – это все газопроводы и оборудование республики. У нас получилось оцифровать объекты таким образом, что информация со всех видов учета – регламентированная, производственная и имущественная – собиралась в единую картину.

Именно на проекте внедрения системы управления имуществом в Газпроме РБ мы и пришли к той технологии, про которую я вам сейчас хочу рассказать. Потому что из 600 человек пользователей, которые оцифровывали всю информацию по этим газопроводам, 550 человек были производственными рабочими. Это люди, которые не только с 1С никогда не работали, они и компьютером-то толком раньше не пользовались. Поэтому нам нужна была такая система, в которую люди в правильном порядке будут вводить сложнейшую, разную информацию, не ошибаясь. И мы такую систему сделали при помощи той технологии, про которую я хочу рассказать.

Потом мы эту технологию отработали в проектах автоматизации производственных процессов в производственных компаниях с многопередельным производством.

Продолжая рассказ о себе, моя фишка в том, что я:

  • владею технологией построения и оптимизации процессов;

  • имею практический опыт делать это;

  • умею подбирать инструменты автоматизации так, чтобы процессы разработки и внедрения работали на системном уровне;

  • и в качестве аналитика могу возглавить эти процессы разработки и внедрения.

 

Почему нам потребовалось менять общепринятую технологию автоматизации?

Первая проблема заключается в том, что, в отличие от регламентированного учета, правила ведения которого прописаны государством и налоговой, производственный и управленческий учет в каждой компании ведутся по-своему.

При этом на протяжении моей длительной профессиональной деятельности, я не видела в компаниях таких людей, которые владеют полностью всей картиной бизнес-процессов на предприятии, понимают, кто что и зачем делает – хотя бы по ролям.

Поэтому, когда мы начинаем спрашивать сотрудников компании о том, как они ведут свои производственные процессы, их ответы могут быть похожи на хаос, который автоматизировать нельзя.

Разберем многопередельное производство – это когда для продукции нам нужно произвести какие-то детали, потом собрать узлы, подузлы. Потом из этих узлов, подузлов собрать саму продукцию. Куча переделов.

Первая задача, которую надо решить на производстве – это рассчитать потребность в выпуске продукции, узлов и деталей. Казалось бы, у нас позаказное производство: берем заказы, рассчитываем потребность, разузловываем – и выпускаем столько узлов и деталей. Нет, совершенно не так.

  • Продукцию мы действительно будем выпускать с учетом потребностей заказов.

  • Но по поводу узлов и подузлов нам нужно понимать, что когда мы их начинаем производить, там будут нестандартные ситуации, брак и так далее. Нам нужно это учесть и выпустить с запасом.

  • И еще нам надо понимать, что узлы и подузлы производятся заранее и лежат на складе – на это количество нужно скорректировать количество к запуску в производство.

  • И еще при планировании количества производимых деталей мы зависим от оборудования. Например, по заказам нам нужно выпустить 15 изделий, общее количество требуемых деталей определенного вида – 150 штук. Но оборудование для отливки этой детали требует выпуска на 2000 штук – так и получается новое количество.

Когда нам это рассказывают, нам кажется, что это какой-то противоречивый бред. На самом деле вполне нормальная логика.

После того как производство эту потребность в выпуске деталей, подузлов и узлов рассчитало таким сложным образом, нам нужно понять – есть ли у нас материалы и комплектующие для того, чтобы все это выпустить? И в какие сроки наше оборудование все это может выпустить?

Здесь появляются две задачи:

  • Или оборудованию нужно несколько месяцев, чтобы выпустить все нужные детали;

  • Или участок сборки у нас не-дозагружен, и нам нужно искать, чем его до-загрузить.

  •  

Чтобы выпустить продукцию в срок (у нас же сроки отгрузки есть), часть производства отдают внешнему производителю. И получается, что одни и те же детали и узлы производятся:

  • собственным производством – это своя цепочка процессов;

  • и внешним производителем – это совершенно другая цепочка процессов.

И получается, что вроде как процессы не готовы к автоматизации, но без автоматизации эти процессы в принципе работать не могут – эти проблемы я на слайде пометила красным.

Самая большая беда заключается в том, что очень многие операции этого процесса и все необходимые для них расчеты невозможно выполнить типовыми средствами.

 

Почему нам не подходит типовой вариант – когда мы описываем процессы «как есть» и «как будут», разрабатываем и внедряем?

  • Первый этап – описываем процессы «как есть». Получаем противоречивую информацию о процессах, неполную. Мы понимаем, что она неполная. Но мы при этом даже не подозреваем, насколько она неполная. Хорошо. Описали, этап закрыли, все нам подтвердили.

  • Следующий этап – начинаем моделировать. На этапе моделирования у нас две «бомбы замедленного действия».

    • Первая бомба – мы моделируем, имея на вход неполный объем информации. Причем мы даже не подозреваем, какую именно информацию мы не знаем, и как она потом перевернет нашу модель.

    • И вторая бомба – по результатам обсуждения этой модели с заказчиком нам кажется, что мы с ним все согласовали. На самом деле заказчик – не специалист. Он смотрит на наши таблицы, на ситуацию, которую мы ему описываем, и ему все нравится. Но он это читает как постороннюю книгу. У него не получается совмещать действия, которые ему нужно производить, с той картиной, что мы ему нарисовали.

  • Дальше мы настраиваем, разрабатываем.

  • Приносим внедрять, и начинается: «Вы все не так сделали!» – «Почему не так? У нас же все записано – вы так говорили!». На что получаем аргумент, который мне больше всего нравится: «Да, мы так говорили, но думали, что будет не так». Ну тут уже «против лома нет приема».

 

«У нас еще несколько принципиальных требований к автоматизации» © Заказчик

 

К этому добавляется несколько принципиальных требований от Заказчика:

  • Заказчик требует, чтобы все процессы всех подразделений в результате автоматизации свелись в единую картину. Даже если мы их сведем, это будет наша картина мира, и она Заказчику точно не подойдет, если у него нет человека, который имеет всю эту картину в голове.

  • Заказчик говорит: «Сделайте нам такую программу, которая нас заставит работать как надо». Казалось бы, есть инструкция – пусть ваши люди работают по инструкции. Но если программа позволяет выполнить пятый шаг, не выполнив первые четыре, независимо от инструкций и регламентов, первые четыре шага выполнять никто не будет – это естественно.

  • Заказчик просит: «Сделайте так, чтобы мы от разработчика не зависели». Но мы же показали, что эти требования типовыми средствами не решить. Получается, что нужно ломать типовую. А если разработчик начнет ломать типовую – лучше вам с этим разработчиком не расставаться, это наш хороший совет.

  • Заказчик: «Мы не хотим менять типовую, нам не нужны проблемы с обновлениями». Ну как это сделать-то?

  • И прям вишенка на торте: «Мы хотим поменять в системе все, не останавливая ее работу, «на лету». Недавно один акционер сказал нам интересную вещь: «Мы сейчас едем на пассажирском поезде, а к концу проекта хотим ехать на Сапсане, не заезжая ни в какое депо на ремонт».

Такие требования заказчика – вторая проблема, из-за которой мы не можем использовать типовой подход к автоматизации.

Хаос автоматизировать нельзя – с этим я полностью согласна, но если подобрать соответствующие инструменты и технологию, то можно. Это я вам сейчас и хочу доказать.

 

Суть технологии

 

Переходим к технологии, которая призвана помочь нам выполнить противоречивые требования от заказчика – они перечислены на слайде сбоку:

  • Первое – мы не трогаем типовую, мы разрабатываем надстройку над типовой в виде надсистемы.

  • Эту надсистему можно настроить под конкретные особенности деятельности каждой компании с учетом конкретных этапов и операций для конкретных бизнес-процессов.

  • Надсистема содержит:

    • внешние обработки – то, что мы называем рабочими местами;

    • структуру данных для того, чтобы сами обработки могли работать;

    • и структуру данных, чтобы эти обработки могли между собой взаимодействовать.

  • Сами обработки позволяют работать с большим объемом информации, который мы показываем в удобном виде каждому пользователю для его конкретной задачи. С помощью обработок пользователи:

    • отражают в системе все необходимые операции и выполняют все необходимые действия с данными;

    • создают все необходимые типовые документы;

    • и заполняют их в правильном порядке – получается, что мы от типовой конфигурации не отходим, мы просто подменяем работу в типовой этим механизмом.

  • Этот подход помогает нам последовательно автоматизировать отдельные процессы и функции: один шаг автоматизировали – переходим на следующий шаг.

С помощью этой надсистемы нам удается соблюсти все перечисленные выше требования заказчика.

Так выглядит отдельное рабочее место. Мы создаем большой массив данных, который нужен пользователям. И каждая закладка содержит именно тот разрез, который ему нужен для работы.

Как я уже говорила, кнопки, запускающие процедуры, связаны с этапами процессов – это значит, что нельзя утвердить план, не сформировав его. Наша система не позволяет выполнять пятый шаг, не выполнив первые четыре, только потому что для пятого шага не будет нужной информации. При этом не нужны ни инструкции, ни регламенты, ничего.

На слайде показано рабочее место, которое формирует план производства на день. Справа перечислены все действия, которые выполняются в ходе работы с этим рабочим местом.

Понятно, что для того, чтобы сформировать План на день или Сменно-суточные задания, люди это все тоже делают – только они это делают в головах, на бумажках, в эксельках, еще где-то в гугл-документах. А у нас система идет по алгоритму и выполняет эту работу.

 

Сквозной процесс. Формирует границы полной надсистемы

 

Я описала вам рабочее место, но для того, чтобы описать всю подсистему, нужно уметь работать со сквозными процессами – процессами, которые проходят через много подразделений, через много ролей.

Опишу вам сквозной процесс выпуск продукции крупными этапами:

  • Процесс выпуска продукции начинается с планирования. Результат планирования – это некая потребность.

  • Эта потребность поступает на вход диспетчеру, который уже рассчитывает возможность выпуска по обеспечению материалами, доступности рабочих центров, определяет необходимость дозагрузки и т.д. В результате выполнения всех этих действий у него появляется Сменно-суточное задание.

  • Это Сменно-суточное задание поступает на вход мастерам участков, и уже мастера участков назначают исполнителей, отражают факт выпуска – выполняют все эти оперативные вещи.

  • Дальше у нас формируется партия, она поступает на контроль,

  • И после контроля у нас появляется годная и негодная продукция, которая поступает на склад.

Такой сквозной процесс выпуска есть в любой компании с многопередельным производством.

Подсистема, которая работает с этим сквозным процессом, содержит рабочие места, перечисленные на слайде. Взаимодействуют они следующим образом:

  • На выходе «Рабочего места Планирование производства» появляется документ «План производства» по определенному сценарию.

  • На выходе «Рабочего места Диспетчера» появляется вся цепочка производственных документов в нужных статусах.

  • «Рабочее место Мастера» закрывает все эти документы,

  • А «Рабочее место Контролера» мы реализовывали в своей надстройке, потому что в типовой конфигурации этой функциональности нет.

Эта технология отличается от типового подхода, потому что она содержит в себе очень сильную консалтинговую составляющую.

 

Этапы разработки надсистемы у нас тоже отличаются от типовых этапов:

  • Первый этап – обследование. Этот этап требует хороших компетенций и глубокого понимания, как работают процессы в компаниях. Можно сказать, что составляющие обследования входят во весь проект. В начале этого обследования мы определенным образом создаем матрицу процессов – собираем требования к автоматизации, которые у нас идут не просто единым списком, а сгруппированные по процессам. На основании всей этой информации мы уже можем сказать, какие нужны рабочие места, и какие функции эти рабочие места должны выполнять.

  • Дальше мы расставляем приоритеты в этих потребностях – в каком порядке разрабатывать. Разработка каждого рабочего места, в свою очередь, состоит из этапов:

  • Первый этап – моделирование. Оно начинается с того, что определяются роли пользователей, которые будут работать с этой подсистемой. И описывается порядок работы сквозного процесса с учетом всех ролей пользователей.

    • После того как будет это все описано, мы рисуем интерфейсы рабочих мест и выводим туда информацию, которая нужна людям, чтобы сделать тот или иной шаг по своему процессу.

    • По результатам согласования модели с заказчиком, рождается ТЗ на разработку и рекомендации по организационным мероприятиям.

  • Второй этап – разработка MVP версии.

    • У нас есть порядок работы, и мы разрабатываем минимально жизнеспособный продукт. Делаем надстройку, которая содержит все рабочие места этого этапа, все функции, все взаимосвязи между ними.

    • При этом мы корректируем порядок работы пользователей и эту систему отдаем сотрудникам заказчика.

  • Третий этап – разработка полной версии. Заказчик уже начинает работать в нашей, в этой системе. Он начинает говорить, так ему или не так – мы все это дорабатываем. И по обратной связи, полученной от заказчика, дорабатываем готовый вариант.

  • Четвертый этап – внедрение. При таком подходе внедрение проходит замечательно, потому что заказчик в разработке этой системы принимал самое непосредственное участие.

 

Матрица процессов. Это список процессов + связи между процессами

 

Расскажу о матрице процессов – она содержит в себе два серьезных инструмента: список процессов плюс все взаимосвязи между процессами.

 

Чтобы составить матрицу процессов, тоже используется технология системного подхода.

Сначала выделяются виды деятельности производственной компании – я уверена, что виды деятельности, которые перечислены на этом слайде, есть в любой компании.

 

Дальше для каждого вида деятельности составляется список процессов.

И потом для каждого процесса описываются этапы или процессы, из которых он состоит.

Фишка в том, что информационный выход одного этапа обязательно должен быть входом в какой-то следующий этап – в этом и есть связь между процессами.

Итак, матрица процессов позволяет нам увидеть слона целиком. С ее помощью мы, заходя на проект, видим всю картину. И потом мы последовательно, шаг за шагом, просто разрабатываем эти рабочие места.

Когда заказчику чего-то не хватает, они просят нас что-то в этих рабочих местах доработать. Лояльность и мотивация заказчика к автоматизации при таком подходе очень радует душу внедренца.

 

Карта путешествия пользователя – дорожная карта разработки Рабочего места

 

Карта путешествия пользователя – это, по сути, дорожная карта разработки рабочего места и вообще автоматизации.

Карта путешествия пользователя содержит не только то, что пользователь делает в программе, а еще и то, где пользователь берет информацию, когда и в каком виде он эту информацию вносит в систему.

По функциональности эта карта похожа на карту путешествия клиента, но это все-таки немного другое.

 

Карта путешествия пользователя может выглядеть различным образом.

 

Мы используем обыкновенный текстовый формат, но мы его заполняем по определенным правилам – каждый шаг пользователя описывается по определенному шаблону.

Фишка этой карты путешествия пользователя в том, что:

  • На этапе моделирования сотрудники заказчика видят не абстрактные таблицы и схемы, а описание того, что конкретно они будут делать. На этом шаге они замечательно включаются в работу. Например, они могут поспорить, что это не то, что они могут делать. То есть, сотрудники очень рано начинают понимать, как будет работать система, которая в принципе еще не существует.

  • Дальше, когда мы разрабатываем MVP-версию, этот порядок становится сценарием тестирования – т.е. MVP-версия должна позволить выполнить все шаги из порядка работы пользователя. В процессе разработки мы этот порядок при необходимости корректируем. Получается, что нам, по сути, не нужно писать инструкции. Благодаря этому подходу сотрудники заказчика сами тестируют, сами говорят, где что нужно добавить, удобно им это или неудобно и т.д.

  • И на внедрении нас еще ни разу не просили написать инструкции, потому что люди уже умеют работать – у них есть порядок работы пользователя.

Этот инструмент позволяет вовлечь сотрудников заказчика на ранних этапах проекта и снимает очень большие риски.

 

Технология, доведенная до совершенства, практически неотличима от магии

Итак, я вам рассказала про технологию, которая позволяет сделать очень многие вещи, но самое главное, она позволяет заходить в проекты, где процессы заказчика, казалось бы, не готовы к автоматизации.

При помощи этой технологии вы можете:

  • Расширить рынок продаж своих продуктов. Эта технология позволяет идти в те проекты, где, например, у вас нет опыта, или есть большие риски, что что-то не получится. Потому что на первом шаге причесываются все потребности, все требования для выполнения второго шага. Здесь нет такого, что надо сразу всего этого слона описать, все сделать, а потом героически переделывать.

  • Снизить трудозатраты на разработку.

  • Снизить трудозатраты на внедрение и повысить качество работ.

  • Сократить время и трудозатраты на доработки, потому что все происходит по фактическим данным. Мы ничего не придумываем. Нам заказчик говорит: «Здесь надо поменять на это» – пожалуйста, меняем.

  • Ну и повысить доход от проекта.

Помните, я говорила про свою школу скорочтения и про продвинутые технологии работы с информацией. Любая новая информация в мозгу человека проходит четыре этапа. Это не я придумала, я просто верю, что это работает, и рассказываю.

  • На первом этапе вы даже не догадываетесь, что это существует. Сейчас я вам рассказала, что есть такой подход, его можно использовать. И вы узнали, что да, возможно, что-то там у них получилось.

  • Второй этап – осознанная некомпетентность. Вы уже осознаете, что это существует, но пока в этом вопросе еще не совсем разбираетесь. Вы начинаете искать информацию, что-то спрашивать, что-то еще делать. Сейчас своим докладом я вас перевела на этап осознанной некомпетентности – вы еще не можете взять и использовать.

  • Дальше, когда вы разберетесь, что-то начнете делать, у вас наступит этап осознанной компетентности. Вы будете делать, и вам захочется в чем-то разобраться, что-то спросить, уточнить.

  • Ну и четвертый этап – неосознанная компетентность, когда вы делаете это все на автомате.

Чтобы сейчас перейти на четвертый уровень, вы обязательно должны начать это использовать, и у вас обязательно должны появиться вопросы.

Поэтому спрашивайте, уточняйте, используйте!

 

Вопросы

 

Мне действительно кажется, что за методологией рабочих мест и их внедрением – большое будущее. И мы уже пытались делать то же самое. Но у нас не получилось обойтись без доработок – например, когда в базовых регистрах конфигурации ERP не хватает какой-то аналитики. Нам пришлось в каждый документ добавлять какую-то аналитику и делать доработки, чтобы эти документы писали данные в регистры. Мы без этого не смогли обойтись.

У нас получилось. Я не разработчик и не знаю, как конкретно у него получилось не дорабатывать типовые, но получилось. Можно будет разобрать ваш конкретный пример и сказать, где можно было обойтись без доработки типовой. У нас, видимо, использовался нестандартный подход.

На скольких проектах эта технология вами использовалась? «Газпром» только? Или где-то еще?

Мы использовали эту технологию на проекте «Газпрома». Потом в производственной компании, которая производит автосигналы для спецмашин. И в производственной компании, которая производит пожарную сигнализацию.

Всего – в трех компаниях с многопередельным производством.

Я правильно понимаю основную идею, что вы не трогаете типовую функциональность, вы разрабатываете интерфейсные части для каждого участника игры, для каждого пользователя, который в этом работает? Если сущность действий человека в интерфейсе совсем не соответствует той логике, заложенной в рамках ERP, вы все равно ищете какие-то сущности, на которые опираетесь в рамках типовой?

Я считаю, типовая 1С:ERP – замечательный продукт. В ней есть очень хорошая разветвленная система хранения информации.

Вы говорите, что мы не столкнулись с такими вещами, которые нельзя типовыми реализовать. Но я специально вначале много времени потратила, описывая тот процесс, который мы автоматизировали – его типовыми средствами автоматизировать нельзя, вообще нельзя. Процессы, которые мы автоматизировали в трех проектах, не решаются типовыми средствами 1С:ERP вообще никак. Тем не менее у нас получилось это решить.

Но каждый конкретный случай опять-таки надо разбирать.

Вы говорите, что в основном используете текстовое описание процессов. С чем это связано? Вам неудобно описывать бизнес-процессы с помощью интерфейсных блок-схем или BPMN? Почему текст?

Согласитесь, что описание процессов в различных нотациях – это иностранный язык, которым владеем мы, внедренцы. Но этим языком не владеют заказчики. Они простые люди, которые выполняют свои производственные функции.

Одна из главных фишек этой технологии, что мы за заказчика не придумываем, как ему работать. Мы стараемся всеми силами включить заказчика. И такое текстовое описание – это то, что ему понятно.

Действительно, если мы вместе с заказчиком смоделировали интерфейс, в котором он будет работать, для него потом увидеть в реальной программе кнопочку в этом месте – это позитив. Но он может остаться недоволен, если мы просто текстом описали, что должна быть кнопочка слева – она может быть не того размера, не того цвета.

Вы немного упрощаете. Неважно, с какой стороны кнопочка. Важно, что сотрудник имеет всю информацию для того, чтобы принять какое-то решение и выполнить какое-то действие. Именно на это мы делаем упор.

Я просто утрировал ситуацию. Но почему вы считаете, что текст удобнее?

Текст понятнее заказчику. Мы с ним разговариваем на одном языке. И поэтому, когда мы ему приносим готовое, у него не возникает вопросов: «Я думал, что будет не так».

Именно поэтому я и говорила про свою школу скорочтения и про продвинутые техники работы с информацией. Это все туда. Человек не может осознавать непонятные вещи, и работать с ними не может – корни в этом.

Что делать с вашей технологией, если процессы заказчика сложились настолько давно, и они настолько запутаны, что пользователи сами до конца не могут вам помочь их описать?

Поскольку я владею технологией системного подхода, я для любой компании могу разложить любой процесс и его взаимосвязи. Мне для этого не нужно заходить в эту компанию и кого-то спрашивать.

И мы, когда идем на обследование, не спрашиваем сотрудников, как они работают. Потому что есть эта технология, которая позволяет составить эту матрицу процессов. Надо просто знать эту технологию.

То, что у заказчика процессы запутаны, не значит, что у него там что-то делается по-другому. У него все равно есть базовый процесс – например, процесс выпуска продукции. Для каждой операции базового процесса есть какая-то потребность, которая включает следующий процесс.

А потом все это складывается просто как пазл. Вы просто не знали, что так можно, но так можно – хотя дальше еще надо разбираться.

Чтобы поставить задачу на разработку рабочего места, аналитик должен провести связь между потребностями пользователей и тем, как работает типовая система. Но при этом вы говорите, что типовая конфигурация не предусматривает того поведения системы, которое вы в нее заложили. Здесь у меня возникает разрыв шаблона. Что вы имеете в виду?

Сначала мы описываем то, что должен сделать пользователь – порядок его работы. Потом, естественно, мы смотрим, как это можно сделать в системе.

Если это можно сделать типовыми средствами, это понятно и логично, мы там рабочее место не делаем.

Мы делаем рабочее место только там, где типовая система не может позволить ему выполнить свои действия, которые ему нужны.

А так, если что-то работает – например, расчет потребностей для закупок работает замечательно – пожалуйста, работайте, мы их туда и отправляем.

В своих рабочих местах мы реализуем связи между цепочками обязательных шагов, делаем туда перекидку, заполняем какие-то нужные документы, какие-нибудь регистры – то, что надо.

И дальше то, что можно делать типовыми.

Если я эти регистры заполню руками, у меня система точно так же будет работать?

Если вы заполните эти регистры руками в правильном порядке – полностью все, что необходимо – то да.

Получается, чтобы проверить работоспособность рабочего места, я должна провести все эти манипуляции?

Конечно, контрольные примеры делаются сначала все на типовой. Только там, где типовая не отрабатывает, включается наша мощная штука.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

10 - 12 октября 2024 года состоится конференция INFOSTART EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Администрирование серверов 1С и СУБД. HighLoad оптимизация
  • Инструментарий разработчика. Приемы и методы разработки 
  • Интеграция и обмен данными 
  • Мобильная разработка и чат-боты 
  • Управление проектом и продуктом 
  • Управление командой 
  • Управление ИТ 
  • Мотивация, лидерство и личная эффективность 
  • Идеи и тренды в разработке

INFOSTART EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Что делать, если моделировать нечего, разработка с "0"

Работа с требованиями Проектирование Удобство использования (UX) Программист Бесплатно (free)

Расскажем о том, как снизить риски при разработке мобильных приложений, новых конфигураций или целых подсистем «с нуля». Материал будет актуальным и для компаний-интеграторов, и для сотрудников внутренних ИТ-отделов в производственных или торговых компаниях.

17.04.2024    1140    15    Vladimir_Konyrev    1    

6

Нужно ли аналитику 1С знать конфигурирование?

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    1860    0    otkalo    1    

12

ЭП для сотрудников с «человеческим» лицом

Кейсы автоматизации Бухгалтер Пользователь Бесплатно (free)

Статья посвящена тому, как безболезненно перейти на кадровый электронный документооборот (КЭДО). Расскажем про варианты электронной подписи, предусмотренные законом 63-ФЗ, перечислим набор внутренних регламентов, которые необходимо выпустить для перехода на КЭДО, и покажем реальные кейсы по автоматизации КЭДО в организации.

19.01.2024    1152    0    AleksKate    5    

6

Как мы автоматизировали работу диспетчерской службы

Кейсы автоматизации Энергетика и ЖКХ Бесплатно (free)

Делимся опытом автоматизации работы аварийно-диспетчерской службы.

18.01.2024    888    0    slavik27    8    

5

Трансформация подходов в работе бизнес-аналитика

Анализ бизнес-процессов Бизнес-аналитик Бесплатно (free)

Профессия аналитика в индустрии 1С имеет множество комбинаций названий и слишком размытые границы функциональности. О том, что будет с профессией бизнес-аналитика в будущем, пойдет речь в статье.

15.01.2024    974    0    chavalah    3    

7

Как мы автоматизировали башню раздачи воды

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    1690    0    slavik27    4    

14

Как искусственный интеллект помогает в работе с требованиями

Работа с требованиями Бесплатно (free)

С выходом ChatGPT стала общедоступна генерация текстов, очень похожих на творчество человека. Использование этой технологии может здорово облегчить вам жизнь и избавить от рутины, но только если вы сами хорошо понимаете – чего вы от него хотите, в каком виде и в какой последовательности. О том, как применить генеративные модели в работе аналитика, пойдет речь в статье.

22.12.2023    2450    0    Ykkks    4    

16

Поговорим о НФТ

Работа с требованиями Бесплатно (free)

Проработка нефункциональных требований (НФТ) часто вызывает трудности у аналитика, но если этими требованиями пренебречь, вероятность проблем в проекте увеличивается. Расскажем о том, что такое нефункциональные требования, почему они важны, как их классифицировать и как выстроить процесс работы с ними так, чтобы они помогли улучшить конечный продукт.

21.12.2023    1689    0    user1909204    0    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. vbalan 8 26.10.23 18:15 Сейчас в теме
Гюльнара, добрый день

Ваша технология - это очень интересно.

Расскажите пожалуйста вот про это:

"Надсистема содержит: ... структуру данных для того, чтобы сами обработки могли работать..."

В Вашем решении структура данных типовая? А если нет - как храните?
2. user1754524 106 26.10.23 20:15 Сейчас в теме
(1) Да, мы используем типовую структуру там, где типовых механизмов достаточно. Там, где типовые механизмы не имеют нужной функциональности, или нужных вообще не существует - создаем свои объекты - справочники, документы, регистры, ...
3. Andreeei 48 31.10.23 09:10 Сейчас в теме
> Там, где типовые механизмы не имеют нужной функциональности...- создаем свои объекты - справочники, документы, регистры, ...

Допустим, в ЕРП заказчику необходимо произвольно редактировать наборы в документах, в том числе, менять / удалять основную комплектующую и/ или ее характеристику, при этом модифицировать наименования наборов и задавать количество. Т.е. в документе может быть несколько наборов, полученных из исходного, которые могут отличаться составами, наименованиями, количествами. В печатных формах наборы должны быть выведены каждый со своим наименованием, комплектующими, и в заданном пользователем количестве.

Интересно, как пристроить сбоку некое рабочее место без вмешательства в типовую? Продублировать и подменить все объекты и формы с наборами с добавлением в них недостающих реквизитов типа идентификаторов наборов, наименований и количеств? Как-то слишком громоздкое получится решение. И таких ситуаций множество, вернее даже почти все, что сразу приходят в голову.

Или ваша технология не применима к мелким задачам?

Можно ли где-то посмотреть пример ее применения?
4. user1754524 106 31.10.23 11:07 Сейчас в теме
(3) Добрый день!
Я поняла ваши вопросы, но вот смотрите, какая ситуация.
В этой технологии важно умение работать с процессами на экспертном уровне
Сначала прорабатываются процессы - выделяются, связываются между собой, и только потом подбираются, разрабатываются, настраиваются механизмы 1С

"необходимо произвольно редактировать наборы в документах, в том числе, менять / удалять основную комплектующую и/ или ее характеристику, при этом модифицировать наименования наборов и задавать количество" - вот в такой формулировке - я вам вообще не смогу ничего ответить.
А вот если опишите словами конкретный процесс почему возникает такая потребность, зачем надо менять основную комплектующую или характеристику, .....Я вам смогу ответить, как это автоматизируем мы, используя вышеизложенную технологию

"Интересно, как пристроить сбоку некое рабочее место без вмешательства в типовую?" - 1С все это позволяет сделать - работу типовых объектов мы не дублируем, решения получаются не громоздкими.

Не понимаю, что вы называете мелкими задачами, если опишите конкретный процесс словами, который считаете мелкой задачей - я смогу сказать применима или нет

Пример применения я пока только показываю на курсе "Автоматизация производственных процессов. Практические приемы и инструменты аналитика", это не реклама, просто только сейчас "руки дошли" до описания кейсов, скоро сделаем видео, можно будет посмотреть
5. Andreeei 48 31.10.23 11:54 Сейчас в теме
(4) > почему возникает такая потребность, зачем надо менять основную комплектующую или характеристику

Чтобы облегчить участь пользователей, которым в противном случае пришлось бы множить наборы. А так есть базовые наборы, и от них получаются множества похожих (именованных немного иначе) наборов, с немного другими составами.

Например, если у основной комплектующей есть множество характеристик, то при использовании типовых возможностей нужно заводить наборы на каждую характеристику. Здесь же можно использовать существующий набор, и при добавлении его в документ менять характеристику основной комплектующей и наименование, и дальше использовать это в печатных формах.
6. user1754524 106 31.10.23 12:43 Сейчас в теме
(5) Можете привести конкретный пример из реальной жизни. Я пока продолжаю не понимать, о чем конкретно идет речь?
7. Andreeei 48 31.10.23 12:45 Сейчас в теме
(6) Это и есть конкретный пример из реальной жизни)
8. user1754524 106 31.10.23 13:28 Сейчас в теме
(7) "если у основной комплектующей есть множество характеристик" это пример на языке разработчиков, он не привязан к объектам физического мира.
А если напишите что это за продукция, как звучат характеристики, из каких физических предметов состоят наборы, тогда я смогу вам сказать свое мнение и, возможно, ответить на ваш вопрос.

Суть в том, что вы уже решили, что это может быть реализовано в 1С только тем способом, который вы описываете
Скорее всего есть и другие решения - как это реализовать по другому, не по вашему. не привязывая наборы к характеристикам

Но для обсуждения других решений нужна конкретика - названия продукции, характеристик, наборов, предметов, как они звучат в физическом мире, а не на языке разработчика 1С
9. Andreeei 48 31.10.23 16:47 Сейчас в теме
(8) Допустим, в физическом мире есть наборы "Мебельный гарнитур черный" состоит из комплектующих "Стол черный" (1 шт) и "Стул черный" (1 шт), 2); "Мебельный гарнитур белый" состоит из комплектующих "Стол белый" (1 шт) и "Стул белый" (1 шт); и прочие цветные наборы всех цветов радуги.

В ЕРП наборы используются для удобного подбора в документы (например, в заказы клиентов), и для группировки товаров в печатных формах примерно так:

- "Мебельный гарнитур черный" ( 1 шт) :
-- "Стол черный" (1 шт)
-- "Стул черный" (1 шт)

- "Мебельный гарнитур белый" ( 1 шт) :
-- "Стол белый" (1 шт)
-- "Стул белый" (1 шт)

В типовом функционале, чтобы это использовать, требуется завести все варианты набора (по количеству цветов в данном случае).

Беда в том, что количество наборов (в реальной жизни) быстро становится слишком большим, и работать с ними становится не удобно.

Поэтому родилась идея - держать только некий основной набор, пусть, например, черный (или бесцветный, неважно). Если надо продать, например, белый набор, то при подборе комплектующих в заказ выбираем основной набор, меняем характеристики комплектующих на белый цвет, и переименовываем набор в документе так, как надо.

Получается примерно тоже самое, что в типовом функционале, но количество наборов намного меньше.

(Да, в наборе еще может быть другое количество стульев, да и столов тоже, и может быть добавлена табуретка))

(И наборы должны сохранятся при создании при создании заказ на основании коммерческого предложения, при создании реализации на основании заказа...)
11. user1754524 106 31.10.23 21:27 Сейчас в теме
(9) Конечно, каждая задача - это отдельная проработка, но вот так, навскидку, мы вот в этом направлении будем делать такую задачу:

Создадим РМ где не нужно будет выбирать набор из кучи ранее созданных, подбирать сам НАБОР будет система

Создаем свой справочник, который содержит шаблоны НАБОРОВ, с которыми будет работать только наше РМ для удобства подбора пользователю

Т.е в отдельной форме ввода менеджер выбирает шаблон набора из нашего справочника, дополняет его всем, что надо, выбирает цвет. жмет на кнопку проверить
Наша обработка ищет такой набор, если нашла - подставляет его в Заказ
Если не нашла - менеджер жмет на кнопку создать, система создает новый и подставляет в документ

Т.о. наборы будет формировать система типовыми средствами и это не создаст никаких сложностей для пользователя
10. user1754524 106 31.10.23 17:09 Сейчас в теме
(9) О, спасибо за описание процесса и. можно, последний уточняющий вопрос?

Для того,чтобы этот алгоритм реализовать, вы внесли изменения в типовую?
Какие объекты изменили? Не надо подробно, просто небольшое перечисление, это для того, чтобы понять - есть разница в наших подходах к решению или, действительно нет

Я вам по нашему возможному решению чуть позже отвечу, сейчас занята буду, 5 занятие курса сегодня провожу
12. Andreeei 48 01.11.23 10:16 Сейчас в теме
(11)
> Для того,чтобы этот алгоритм реализовать, вы внесли изменения в типовую?

Да, реквизиты добавили в типовую, процедуры изменили расширением.

> Какие объекты изменили?

- Справочник "Варианты комплектации номенклатуры";
- Обработку "Редактирование наборов";
- Табличные части документов, где используются наборы;
- Обработки заполнения для копирования наборов между документами;
- Процедуры формирования печатных форм.

Самая большая неприятность в том, что печатная форма УПД (документа реализации) строится на основании табличных частей "Виды запасов" и "Товары", причем виды запасов и товары могут быть в самых разных соотношениях, одному товару может соответствовать несколько видов запасов, и наоборот нескольким одинаковым товарам может соответствовать одна строка с видом запасов. Распределять строки одной таблицы по строкам другой таблицы при формировании УПД бывает долго (зависит от размеров таблиц товаров и видов запасов), поэтому пришлось присобачить в документ реализации еще одну свою расширенную таблицу видов запасов, с реквизитами про набор (идентификатор набора, наименование набора, количество наборов), заполнять эту таблицу вместе с заполнением типовой таблицы "Виды запасов", и использовать ее вместо типовой.

Примерно так.
13. user1754524 106 01.11.23 11:06 Сейчас в теме
(12)
Ну вот, смотрите - сколько изменений пришлось делать в типовой.

Я наше примерное решение выше описала

Отличие нашего решения, что мы направляем усилия на то, чтобы максимально использовать типовые объекты и при этом автоматизировать рутинные действия по созданию цепочек всех нужных документов

В нашем решении - мы будем не просто автоматизировать создание НАБОРОВ.
Мы выстроим действия пользователей в РМ так, чтобы он ввел всю необходимую для автоматизированного создания типовых объектов информацию в нужном порядке и в нужном объеме, для этого заложим контролирующие процедуры в самом рабочем месте, опять-таки не задевая типовые процедуры

При таком подходе - большое количество наборов - вообще не усложняет ни работу, ни процесс - никак

Бонусом - наш процесс выстроит процессы без всяких регламентов

А все типовые процедуры, которые вы вынуждены были изменить - будут работать так, как это задумал их создатель
14. Andreeei 48 01.11.23 11:26 Сейчас в теме
(13)

> А все типовые процедуры, которые вы вынуждены были изменить - будут работать так, как это задумал их создатель

К сожалению нет, например, в печатных формах типовые процедуры сворачивают одинаковые наборы с суммированием их количеств и стоимостей, а надо, чтобы они выводились ровно так, как были заведены в документе. В данном случае, если оставить типовой функционал в покое, и делать все сбоку, то получится неадекватно большой объем работы.

Наверное ваша технология хороша, но ее надо дополнить условиями применения (если, конечно, это возможно, но скорее всего, каждый раз надо очень прилично задумываться, перед тем, как начинать ей следовать))
15. user1754524 106 01.11.23 11:46 Сейчас в теме
(12)
(14) Ну я дальше развивать дискуссию не буду, потому что у меня нет цели именно вас убедить в том, что - "Все бросайте и работайте, как мы!".

Я же написала, что предложенное нами решение - это просто направление - в чем мы думаем по-другому.

Конечно, когда начнем реализовывать вскроется еще куча вещей типа "в печатных формах типовые процедуры сворачивают одинаковые наборы с суммированием их количеств и стоимостей, а надо, чтобы они выводились ровно так, как были заведены в документе".
Но наш практический опыт показывает, что на каждую такую задачу, которую внедренцы обычно решают через изменение типовых объектов, есть решение, которое позволяет их не трогать, потому что это главный принцип нашего подхода к автоматизации

Зачастую я предлагаю разработчику какой-то вариант, на который он сначала смотрит, как на бред, но постепенно, путем обсуждения, мы научились находить решения, которые позволяют нам выполнить наше главное предложение: "Мы реализуем 98% ваших хотелок, при этом все объекты типовой останутся на поддержке"

Ограничений применимости мы пока не встретили, вы вот тоже не смогли привести такой пример, где этот подход не применим

Тут весь вопрос только в вас и в вашем мышлении.
Насколько вы готовы и/или вам интересно выполнять привычные вещи по новому
Нам интересно и у нас это получается
Вот как-то так

Спасибо вам за ваш интерес, за время, которое вы потратили на описание вашего кейса и за ваше мнение!
chng; Zatmesha; Batman; +3 Ответить
Оставьте свое сообщение