Как не разориться на разработке отчётов
На разработку и, главное, доработку отчётов можно потратить кучу денег, если не быть программистом и при этом слушать программистов.
Больше всего на свете программисты любят решать нерешаемые задачи по отчётам. Соединять несоединяемое, объединять необъединяемое, выводить невыводимое. И если программисту дают такую задачу, где он может от души потренироваться в знании запросов и СКД, он будет хлопать в ладошки и прыгать от радости. Заплатить же придётся довольно много.
Отчёты различаются по типу исходных данных:
1. Остатки – выводится остаток какого-нибудь регистра, например – неоплаченные исходящие платежи;
2. Обороты – выводятся обороты по какому-нибудь регистру, например – продажи;
3. Остатки и обороты – выводятся остатки и обороты по какому-нибудь регистру, например – большинство «ведомостей», вроде взаиморасчетов, товары на складах и т.д.
4. Вертикальная мешанина – берутся идентичные по структуре данные, которые потом склеиваются вертикально (одна под другой), чтобы суммировать или наоборот – увидеть разницу. Так работают большинство отчётов план/фактного анализа;
5. Горизонтальная мешанина – берутся разнородные данные, как-то связанные с «отправной точкой» и выводятся в длинную горизонтальную портянку. Например, отчёты, которые сразу выводят и заказы покупателей, и остатки на складах, и долги, и сроки поставок, KPI менеджеров и т.д. В типовых конфигурациях таких отчётов почти не бывает, это обычно придумка «местных».
6. Печатная форма – когда вроде отчёт, а по сути – печатная форма с выводом кучи не связанных между собой данных. В таких отчётах всегда бешеное количество кода. Лучшие примеры – регламентированная отчётность. И всякие прикрепляемые к документам отчёты, вроде «Состояние выполнения» заказа.
По стоимости исходной разработки самые дешёвые – первые три типа. На разработку требуются буквально минуты – выбрать нужную виртуальную таблицу регистра, выбрать ресурсы, установить роли и типы полей, настроить видимость параметров и стартовую настройку. Всё остальное дорисует платформа.
«Вертикальная мешанина» подороже, но если рука у программиста набита, то тоже недорого. Главное сразу сопоставить аналитики и выбрать всё, что нужно – добавлять потом дороже.
Стоимость «горизонтальной мешанины» напрямую, и наиболее всего зависит от правильности исходной постановки задачи. Главное там – определить «отправную точку», т.е. таблицу, относительно которой будет вычисляться всё остальное. Например, это могут быть заказы, продажи, план производства, контрагенты и т.д. Типа «выведи мне всех контрагентов, и вот такую-то информацию по ним».
«Печатная форма» прелестна тем, что и её одинаково дорого и разрабатывать, и дорабатывать. Поэтому тут париться не стоит насчёт того, чтобы сразу, заранее всё придумать. Достаточно определить некую «тему», на которую будет этот отчёт. Хотя, бывают подобные отчёты и «обо всём на свете».
Вернёмся к стоимости и экономии. Больше всего денег уходит на превращение отчёта одного типа в другой. Особенно, если делать это итерационно.
Например, был у вас прекрасный отчёт типа «Остатки» - показывал, сколько и какой продукции ещё надо отгрузить клиентам, по заказам. Проблема начинается с фразы «а добавь-ка мне в этот отчёт информацию, программист…». Например, остаток на складе по каждой позиции. Фигня же, вроде?
Ан нет. Во-первых, отчёт меняет тип – с «Остатков» на «Горизонтальную мешанину», и сразу переходит в разряд дорогущих. Во-вторых, данные плохо сопоставимы, и результат сопоставления сильно зависит от настройки отчёта. Значит, вы лишаетесь большинства возможностей настройки – какую программист сделает, той и будете пользоваться.
В-третьих, адекватно сопоставить эти остатки нельзя – их надо не сопоставлять, а распределять. Программисты очень любят решать задачу распределения в СКД, т.к. это круто и интересно. Но дорого и ненадёжно. Кодом намного проще и надёжнее. Но это уже не в отчёте надо делать.
На разработку и, главное, доработку отчётов можно потратить кучу денег, если не быть программистом и при этом слушать программистов.
Больше всего на свете программисты любят решать нерешаемые задачи по отчётам. Соединять несоединяемое, объединять необъединяемое, выводить невыводимое. И если программисту дают такую задачу, где он может от души потренироваться в знании запросов и СКД, он будет хлопать в ладошки и прыгать от радости. Заплатить же придётся довольно много.
Отчёты различаются по типу исходных данных:
1. Остатки – выводится остаток какого-нибудь регистра, например – неоплаченные исходящие платежи;
2. Обороты – выводятся обороты по какому-нибудь регистру, например – продажи;
3. Остатки и обороты – выводятся остатки и обороты по какому-нибудь регистру, например – большинство «ведомостей», вроде взаиморасчетов, товары на складах и т.д.
4. Вертикальная мешанина – берутся идентичные по структуре данные, которые потом склеиваются вертикально (одна под другой), чтобы суммировать или наоборот – увидеть разницу. Так работают большинство отчётов план/фактного анализа;
5. Горизонтальная мешанина – берутся разнородные данные, как-то связанные с «отправной точкой» и выводятся в длинную горизонтальную портянку. Например, отчёты, которые сразу выводят и заказы покупателей, и остатки на складах, и долги, и сроки поставок, KPI менеджеров и т.д. В типовых конфигурациях таких отчётов почти не бывает, это обычно придумка «местных».
6. Печатная форма – когда вроде отчёт, а по сути – печатная форма с выводом кучи не связанных между собой данных. В таких отчётах всегда бешеное количество кода. Лучшие примеры – регламентированная отчётность. И всякие прикрепляемые к документам отчёты, вроде «Состояние выполнения» заказа.
По стоимости исходной разработки самые дешёвые – первые три типа. На разработку требуются буквально минуты – выбрать нужную виртуальную таблицу регистра, выбрать ресурсы, установить роли и типы полей, настроить видимость параметров и стартовую настройку. Всё остальное дорисует платформа.
«Вертикальная мешанина» подороже, но если рука у программиста набита, то тоже недорого. Главное сразу сопоставить аналитики и выбрать всё, что нужно – добавлять потом дороже.
Стоимость «горизонтальной мешанины» напрямую, и наиболее всего зависит от правильности исходной постановки задачи. Главное там – определить «отправную точку», т.е. таблицу, относительно которой будет вычисляться всё остальное. Например, это могут быть заказы, продажи, план производства, контрагенты и т.д. Типа «выведи мне всех контрагентов, и вот такую-то информацию по ним».
«Печатная форма» прелестна тем, что и её одинаково дорого и разрабатывать, и дорабатывать. Поэтому тут париться не стоит насчёт того, чтобы сразу, заранее всё придумать. Достаточно определить некую «тему», на которую будет этот отчёт. Хотя, бывают подобные отчёты и «обо всём на свете».
Вернёмся к стоимости и экономии. Больше всего денег уходит на превращение отчёта одного типа в другой. Особенно, если делать это итерационно.
Например, был у вас прекрасный отчёт типа «Остатки» - показывал, сколько и какой продукции ещё надо отгрузить клиентам, по заказам. Проблема начинается с фразы «а добавь-ка мне в этот отчёт информацию, программист…». Например, остаток на складе по каждой позиции. Фигня же, вроде?
Ан нет. Во-первых, отчёт меняет тип – с «Остатков» на «Горизонтальную мешанину», и сразу переходит в разряд дорогущих. Во-вторых, данные плохо сопоставимы, и результат сопоставления сильно зависит от настройки отчёта. Значит, вы лишаетесь большинства возможностей настройки – какую программист сделает, той и будете пользоваться.
В-третьих, адекватно сопоставить эти остатки нельзя – их надо не сопоставлять, а распределять. Программисты очень любят решать задачу распределения в СКД, т.к. это круто и интересно. Но дорого и ненадёжно. Кодом намного проще и надёжнее. Но это уже не в отчёте надо делать.
🔥3👍2💯2
На добавление остатка товаров вы потратите больше денег, чем на разработку исходного отчёта. Дальше хуже – получив такой «прекрасный инструмент», вы захотите его развивать. А правильный инструмент (который не отчёт) больше вообще всплывать не будет, даже в разговорах – вы будете только «а добавь-ка мне в этот отчёт информацию, программист…».
Каждая следующая итерация добавления информации будет дороже предыдущей. Как правило, потому, что почти на каждой итерации будет требоваться изменение структуры и способа выборки всего, что уже было в отчёте – иначе не соединится с новыми данными.
Особенно плохо, если вы таким образом «дорабатываете» типовые отчёты современных конфигураций. Всё, что я написал, можно смело умножать на 3.
Лучше держать отчёты тощими, голодными, поджарыми, лёгкими на подъём, настраиваемыми.
А вообще, такие проблемы возникают из-за неверного использования отчётов, непонимания их назначения в системе 1С. Об этом в следующий раз.
Каждая следующая итерация добавления информации будет дороже предыдущей. Как правило, потому, что почти на каждой итерации будет требоваться изменение структуры и способа выборки всего, что уже было в отчёте – иначе не соединится с новыми данными.
Особенно плохо, если вы таким образом «дорабатываете» типовые отчёты современных конфигураций. Всё, что я написал, можно смело умножать на 3.
Лучше держать отчёты тощими, голодными, поджарыми, лёгкими на подъём, настраиваемыми.
А вообще, такие проблемы возникают из-за неверного использования отчётов, непонимания их назначения в системе 1С. Об этом в следующий раз.
👍6
Отвечает Отчёт
Когда кажется, что пора сделать новый отчёт, можно использовать такой приём: представить, что отчёт отвечает на вопрос. Как Оракул, или автоответчик, или чат-бот.
Соответственно, разрабатывать отчёт надо только после того, как станет всё понятно про вопрос, на который он будет отвечать.
Ну, во-первых, а что за вопрос? Один или много? Все ли вопросы ясны? Или как всегда, «сделайте отчёт, а я потом решу, зачем он был нужен». Для таких постановок в любой 1С есть прекрасный отчёт, называется «Консоль запросов».
Во-вторых – а кому? Это мегаважно. Часто бывает, что заказчик просит отчёт не для себя, а «для всеобщего блага». Правда, почему-то считая свои личные требования по гигантскому размеру шрифта и вырвиглазному цветовому оформлению, опять же, служащими всеобщему благу.
Вопрос – он же от человека всегда. От конкретного человека. Или группы конкретных человеков.
В-третьих, а им, человекам, оно надо? Ну т.е. появляется ли у них этот вопрос. А то может по процессу положено, или здравый смысл подсказывает, что им это должно быть интересно, а они плевать хотели.
В-четвертых, а как часто этот вопрос возникает? Не исключено, что раз в жизни, и именно сейчас. Или ответом на вопрос будет понимание, что вопрос глуп.
Вроде, просто и глупо, да? Но 90% отчётов так и лежат без дела. Не верите? Проверяйте. Я проверял, много раз. И типовые, и доработанные, и разработанные.
Оставшиеся же 10 % шуршат так, что сервер устаёт. Потому что отвечают конкретному человеку, на конкретный вопрос в конкретный момент. А необходимость в получении ответа на вопрос, как правило, создана какой-то потусторонней силой («директор по утрам требует»). Вот, такие отчёты делать любо-дорого.
Остальные отчёты, увы, можно не делать. Программистам-то прикольно поупражняться, а деньги компании тратятся зря, будь то внутренняя разработка или заказная на стороне.
Есть, конечно, отчёты, отвечающие на широкий круг вопросов. Есть отчёты, которые, отвечая на один вопрос, создают сразу ещё пачку. Но! Только человеку, которому прям интересно понять, чё тут вообще творится. А это программист или аналитик.
Кстати, крутому аналитику отчёты не нужны. Он просит дать доступ к регистрам. Прям как программист.
Когда кажется, что пора сделать новый отчёт, можно использовать такой приём: представить, что отчёт отвечает на вопрос. Как Оракул, или автоответчик, или чат-бот.
Соответственно, разрабатывать отчёт надо только после того, как станет всё понятно про вопрос, на который он будет отвечать.
Ну, во-первых, а что за вопрос? Один или много? Все ли вопросы ясны? Или как всегда, «сделайте отчёт, а я потом решу, зачем он был нужен». Для таких постановок в любой 1С есть прекрасный отчёт, называется «Консоль запросов».
Во-вторых – а кому? Это мегаважно. Часто бывает, что заказчик просит отчёт не для себя, а «для всеобщего блага». Правда, почему-то считая свои личные требования по гигантскому размеру шрифта и вырвиглазному цветовому оформлению, опять же, служащими всеобщему благу.
Вопрос – он же от человека всегда. От конкретного человека. Или группы конкретных человеков.
В-третьих, а им, человекам, оно надо? Ну т.е. появляется ли у них этот вопрос. А то может по процессу положено, или здравый смысл подсказывает, что им это должно быть интересно, а они плевать хотели.
В-четвертых, а как часто этот вопрос возникает? Не исключено, что раз в жизни, и именно сейчас. Или ответом на вопрос будет понимание, что вопрос глуп.
Вроде, просто и глупо, да? Но 90% отчётов так и лежат без дела. Не верите? Проверяйте. Я проверял, много раз. И типовые, и доработанные, и разработанные.
Оставшиеся же 10 % шуршат так, что сервер устаёт. Потому что отвечают конкретному человеку, на конкретный вопрос в конкретный момент. А необходимость в получении ответа на вопрос, как правило, создана какой-то потусторонней силой («директор по утрам требует»). Вот, такие отчёты делать любо-дорого.
Остальные отчёты, увы, можно не делать. Программистам-то прикольно поупражняться, а деньги компании тратятся зря, будь то внутренняя разработка или заказная на стороне.
Есть, конечно, отчёты, отвечающие на широкий круг вопросов. Есть отчёты, которые, отвечая на один вопрос, создают сразу ещё пачку. Но! Только человеку, которому прям интересно понять, чё тут вообще творится. А это программист или аналитик.
Кстати, крутому аналитику отчёты не нужны. Он просит дать доступ к регистрам. Прям как программист.
🔥10👍2
Порешал в марте интересную задачу про расчёт себестоимости. В УПП, правда, но всё равно прикольно. Тем более, постоянный клиент - таким всегда интереснее помогать.
Решили они, короче, алгоритм распределения затрат поменять. Сколько я не видел таких задач, если речь о многопередельном производстве, сводятся всегда к одному - увидеть затраты в готовой продукции. Ну, сами знаете - что в УПП, что в ЕРП, что в любой другой конфигурации затраты переделов остаются на переделах. Какую долю в с/с готовой продукции занимает электричество и зарплата на переделе № 3 из 14 - вы узнаете только с помощью экселя и калькулятора, потому что до готовой продукции все затраты всех переделов, кроме последнего, добегают по статье затрат "Полуфабрикаты".
Так вот, клиент захотел все затраты переделов, кроме прямых материальных затрат, складывать сразу в готовую продукцию. Если она не выпустилась в тек. месяце - пусть копится до выпуска. Ну, пока вроде терпимо.
А теперь база распределения - их две, и одна краше другой.
Зарплата, говорят, пусть ложится в готовую продукцию пропорционально нормативам трудозатрат. Те лежат в совершенно типовых местах - в тех.операциях. Клиент такой, молодец, у них 100k+ спецификаций, на каждую есть тех.карта, в ней вбиты все тех.операции с нормами времени. Только сдельной зарплаты нет, есть лишь общая сумма. Вот её и надо распределить.
Только сначала, конечно, надо как-то всё разузловать и собрать трудозатраты по всем переделам, чтобы вычислить базу распределения затрат.
Вторая база - прямые материальные. Вроде несложно, даже УПП так умеет, но... Опять же, надо собрать по всем переделам, а их там и 20 бывает. Собрал, чё.
Проблемой было то, что у клиента партионный учёт, даже не РАУЗ. В РАУЗе можно базу распределения прямо запросом вычислять, на лету. В партионном учёте - нет, только заполнять документ "Установка базы распределения затрат". Так и сделал.
Трудозатраты - обработкой заполнения документа. Взял выпуск готовой продукции (известен фильтр по номенклатуре и складу), разузловал, собрал все трудозатраты - вот тебе и база.
Прямые материальные - аналогично, только расчёт себестоимости стал двухшаговым. Сначала делаешь расчёт, чтобы УПП посчитала стоимость прямых материальных затрат и положила их в регистры. После рассчитываешь базу и складываешь в документы "Установка базы распределения затрат". Ну и второй расчёт, который распределяет косвенные по уже известной базе.
Собрать прямые материальные получилось запросом, но лишь потому, что у клиента учёт позаказный. Но получилось в итоге.
Ну и всё, мечта сбылась. Без доработок типовой конфигурации.
Решили они, короче, алгоритм распределения затрат поменять. Сколько я не видел таких задач, если речь о многопередельном производстве, сводятся всегда к одному - увидеть затраты в готовой продукции. Ну, сами знаете - что в УПП, что в ЕРП, что в любой другой конфигурации затраты переделов остаются на переделах. Какую долю в с/с готовой продукции занимает электричество и зарплата на переделе № 3 из 14 - вы узнаете только с помощью экселя и калькулятора, потому что до готовой продукции все затраты всех переделов, кроме последнего, добегают по статье затрат "Полуфабрикаты".
Так вот, клиент захотел все затраты переделов, кроме прямых материальных затрат, складывать сразу в готовую продукцию. Если она не выпустилась в тек. месяце - пусть копится до выпуска. Ну, пока вроде терпимо.
А теперь база распределения - их две, и одна краше другой.
Зарплата, говорят, пусть ложится в готовую продукцию пропорционально нормативам трудозатрат. Те лежат в совершенно типовых местах - в тех.операциях. Клиент такой, молодец, у них 100k+ спецификаций, на каждую есть тех.карта, в ней вбиты все тех.операции с нормами времени. Только сдельной зарплаты нет, есть лишь общая сумма. Вот её и надо распределить.
Только сначала, конечно, надо как-то всё разузловать и собрать трудозатраты по всем переделам, чтобы вычислить базу распределения затрат.
Вторая база - прямые материальные. Вроде несложно, даже УПП так умеет, но... Опять же, надо собрать по всем переделам, а их там и 20 бывает. Собрал, чё.
Проблемой было то, что у клиента партионный учёт, даже не РАУЗ. В РАУЗе можно базу распределения прямо запросом вычислять, на лету. В партионном учёте - нет, только заполнять документ "Установка базы распределения затрат". Так и сделал.
Трудозатраты - обработкой заполнения документа. Взял выпуск готовой продукции (известен фильтр по номенклатуре и складу), разузловал, собрал все трудозатраты - вот тебе и база.
Прямые материальные - аналогично, только расчёт себестоимости стал двухшаговым. Сначала делаешь расчёт, чтобы УПП посчитала стоимость прямых материальных затрат и положила их в регистры. После рассчитываешь базу и складываешь в документы "Установка базы распределения затрат". Ну и второй расчёт, который распределяет косвенные по уже известной базе.
Собрать прямые материальные получилось запросом, но лишь потому, что у клиента учёт позаказный. Но получилось в итоге.
Ну и всё, мечта сбылась. Без доработок типовой конфигурации.
🔥12👏2👍1
Опять согрешил, забрал задачу у программиста. Ну там задача просто шикарная, детектив. И срочная/важная.
Короче, у клиента УПП, некоторое время назад уволился расчётчик. Посадили нового, всё шло неплохо, но... Ровно 9 числа была такая Процедура - ознакомление с расчётными листками. Предыдущий расчётчик где-то как-то в 1С формировал реестр этого ознакомления, и его рассылали по подразделениям.
Догадываетесь, в чём задача? Аааааааа как она это делала?! Её не спросили, она и не сказала видимо, при передаче дел. Связаться с ней, видимо, почему-то нельзя. Ну вот и задача - найдите, где она в 1С этот реестр формировала. У нас была только фотка этого реестра за февраль.
Как пройти мимо? Тем более, программисты полдня искали и не нашли. Реестр выглядит, как отчёт (видно по заголовку, там выводится отбор, как в большинстве отчётов).
Программисты перешерстили все нетиповые отчёты в конфигурации, все дополнительные и внешние, произвольные, печатные формы, доп. обработки и т.д. Нигде ничего.
Я тоже прошерстил (не доверяю программистам, когда они говорят "я везде посмотрел"). Пошёл в журнал регистрации, отобрал по уволившейся расчётчице за 9 число прошлого месяца. Кроме обычных документов, часто встречалось сохранение настроек отчётов. Ну, дальше несложно.
Узнали её пароль, зашли под ней, глянули список отчётов, в которых она сохраняла настройки, и прошли сверху вниз. Оказалось, реестр был сохранённой настройкой типового отчета анализ начислений сотрудникам.
Ну как тут, блин, бросишь решать задачи и будешь только начальствовать? Все квесты и детективы пропустишь.
Короче, у клиента УПП, некоторое время назад уволился расчётчик. Посадили нового, всё шло неплохо, но... Ровно 9 числа была такая Процедура - ознакомление с расчётными листками. Предыдущий расчётчик где-то как-то в 1С формировал реестр этого ознакомления, и его рассылали по подразделениям.
Догадываетесь, в чём задача? Аааааааа как она это делала?! Её не спросили, она и не сказала видимо, при передаче дел. Связаться с ней, видимо, почему-то нельзя. Ну вот и задача - найдите, где она в 1С этот реестр формировала. У нас была только фотка этого реестра за февраль.
Как пройти мимо? Тем более, программисты полдня искали и не нашли. Реестр выглядит, как отчёт (видно по заголовку, там выводится отбор, как в большинстве отчётов).
Программисты перешерстили все нетиповые отчёты в конфигурации, все дополнительные и внешние, произвольные, печатные формы, доп. обработки и т.д. Нигде ничего.
Я тоже прошерстил (не доверяю программистам, когда они говорят "я везде посмотрел"). Пошёл в журнал регистрации, отобрал по уволившейся расчётчице за 9 число прошлого месяца. Кроме обычных документов, часто встречалось сохранение настроек отчётов. Ну, дальше несложно.
Узнали её пароль, зашли под ней, глянули список отчётов, в которых она сохраняла настройки, и прошли сверху вниз. Оказалось, реестр был сохранённой настройкой типового отчета анализ начислений сотрудникам.
Ну как тут, блин, бросишь решать задачи и будешь только начальствовать? Все квесты и детективы пропустишь.
❤🔥7👍4
В четверг очередная встреча с клиентом на Грустную Тему. На прошлой неделе таких было две.
После таких встреч чувствую себя врачом, который сообщает плохую весть.
Тема встречи: "Хотим купить MES-систему на 1С".
Детали могут разниться - например, MES хотят приделать то к ЕРП, то к КА2, то к УПП, то бывает и к УНФ.
Иногда хотят "Запустить MES, который есть в нашей программе 1С".
MES на 1С нельзя купить. Его можно только сделать. Увы.
В четверг очередной клиент об этом узнает и расстроится.
После таких встреч чувствую себя врачом, который сообщает плохую весть.
Тема встречи: "Хотим купить MES-систему на 1С".
Детали могут разниться - например, MES хотят приделать то к ЕРП, то к КА2, то к УПП, то бывает и к УНФ.
Иногда хотят "Запустить MES, который есть в нашей программе 1С".
MES на 1С нельзя купить. Его можно только сделать. Увы.
В четверг очередной клиент об этом узнает и расстроится.
👍5😭2
Пост про MES вызвал неожиданный отклик - и в комментариях, и за пределами канала пообщался с несколькими людьми.
Кроме единственного человека в комментариях, никто работающего MES не видел :)
А я вот чего вспомнил: чуть меньше года назад я выступал на конференции в Питере, и тоже рассказывал про MES!
Ну, не только про него. Ещё про MDM, BI, CRM, PLM, ССП, БДДС, BPM и прочие подобные. И про то, что их объединяет.
Что их объединяет? Купить и внедрить некий Продукт - дорого, очень дорого. А из этого Продукта реально нужны 1-2 инструмента. Бывает - один отчёт.
Так вот, доклад назывался "А чё, так можно было? Дёшево и сердито. Вместо сложно и дорого".
Как будто в тему будет - и про MES, и про всё остальное.
https://www.youtube.com/watch?v=JOZpPTBYyEc
Кроме единственного человека в комментариях, никто работающего MES не видел :)
А я вот чего вспомнил: чуть меньше года назад я выступал на конференции в Питере, и тоже рассказывал про MES!
Ну, не только про него. Ещё про MDM, BI, CRM, PLM, ССП, БДДС, BPM и прочие подобные. И про то, что их объединяет.
Что их объединяет? Купить и внедрить некий Продукт - дорого, очень дорого. А из этого Продукта реально нужны 1-2 инструмента. Бывает - один отчёт.
Так вот, доклад назывался "А чё, так можно было? Дёшево и сердито. Вместо сложно и дорого".
Как будто в тему будет - и про MES, и про всё остальное.
https://www.youtube.com/watch?v=JOZpPTBYyEc
YouTube
Иван Белокаменцев. А чё, так можно было? Дёшево и сердито. Вместо сложно и дорого
Внедрение дорогих и сложных решений вроде BI, MDM, CRM или УХ для вспомогательных целей – не единственный путь, а порой и вовсе тупиковый. О том, как не попасть в УХу, если директор хочет красивые отчёты, и делать дешёвые интеграции, не заморачиваясь с поиском…
👍5
И ещё про MES. Он кто такой? Несколько здоровенных кусков, вроде диспетчеризации, планирования, управления ресурсами, документацией, качеством и т.д.
"Внедрить MES" - это что? Все куски запустить? Половину? Две обработки? Как тогда понять, есть у нас MES или нет?
Или "Внедрённый MES" - это подписанный отзыв?
Вот вам простой пример из практики. Два клиента, на ЕРП, работают уже несколько лет, используют совершенно типовой функционал производства - заказы, этапы и т.д.
В один и тот же месяц оба обращаются с одной и той же задачей - сделай, блин, обработку, чтобы выполнение этапов быстренько прощёлкивать. А то в жизни уже этап выполнен, но до того, блин, неудобно искать его в списке, открывать документ, жать пару кнопок, проводить...
Я удивился - неужели в ЕРП нет рабочего места для быстрого выполнения этапов? Оказалось, нет.
Запросы от клиентов немного различались, правда.
Один хотел две закладки. На одной - вывести невыполненные этапы и дать возможность быстро их закрывать, в т.ч. массово, выделяя несколько сразу. На второй - дерево невыполненных этапов по заказу, и чтоб щёлкнуть - и все этапы заказа стали выполненными.
Второй хотел штрихкодирование. Чтобы из этапа/заказа вылезала печатная форма, на ней ШК или QR, а чуваки в цехе подошли к компу, пикнули, и этап/заказ "выполнился".
У другого нашего клиента такое в УПП сделано. Кто программировал - знает, что тут ничего сложного нет. Чувакам в цехе выдают бумажки, типа маршрутные листы, в них ШК. Когда они закончили - не один заказ, а пачку сразу, чтобы много раз не бегать - подходят к компу в цехе, пик-пик-пик и в УПП создались отчёты производства за смену, под них требования-накладные и перемещения на следующий передел (там многопередельное производство через 21 счёт).
Оттуда, из УПП, идею и взяли.
Один из клиентов пробовал решить эту задачу с помощью мобильного приложения ЕРП, но тоже неудобно, говорит. Мы им вывели в печатную форму QR, можно с телефончика быстро открыть форму этапа и прощёлкать, что он выполнен. Но этапы в жизни выполняются быстрее, не нащёлкаешься. Плюс, нужна некая накопительная асинхронность - прощёлкивать выполнение пару раз в день, сразу по пачке этапов. Неудобно оказалось через мобильное приложение, короче.
Ну, чё делать - поделил трудозатраты на двоих клиентов, сделали одинаковую обработку, выдали, привыкают. За индивидуальные особенности каждый сам заплатил отдельно.
Это - MES?
"Внедрить MES" - это что? Все куски запустить? Половину? Две обработки? Как тогда понять, есть у нас MES или нет?
Или "Внедрённый MES" - это подписанный отзыв?
Вот вам простой пример из практики. Два клиента, на ЕРП, работают уже несколько лет, используют совершенно типовой функционал производства - заказы, этапы и т.д.
В один и тот же месяц оба обращаются с одной и той же задачей - сделай, блин, обработку, чтобы выполнение этапов быстренько прощёлкивать. А то в жизни уже этап выполнен, но до того, блин, неудобно искать его в списке, открывать документ, жать пару кнопок, проводить...
Я удивился - неужели в ЕРП нет рабочего места для быстрого выполнения этапов? Оказалось, нет.
Запросы от клиентов немного различались, правда.
Один хотел две закладки. На одной - вывести невыполненные этапы и дать возможность быстро их закрывать, в т.ч. массово, выделяя несколько сразу. На второй - дерево невыполненных этапов по заказу, и чтоб щёлкнуть - и все этапы заказа стали выполненными.
Второй хотел штрихкодирование. Чтобы из этапа/заказа вылезала печатная форма, на ней ШК или QR, а чуваки в цехе подошли к компу, пикнули, и этап/заказ "выполнился".
У другого нашего клиента такое в УПП сделано. Кто программировал - знает, что тут ничего сложного нет. Чувакам в цехе выдают бумажки, типа маршрутные листы, в них ШК. Когда они закончили - не один заказ, а пачку сразу, чтобы много раз не бегать - подходят к компу в цехе, пик-пик-пик и в УПП создались отчёты производства за смену, под них требования-накладные и перемещения на следующий передел (там многопередельное производство через 21 счёт).
Оттуда, из УПП, идею и взяли.
Один из клиентов пробовал решить эту задачу с помощью мобильного приложения ЕРП, но тоже неудобно, говорит. Мы им вывели в печатную форму QR, можно с телефончика быстро открыть форму этапа и прощёлкать, что он выполнен. Но этапы в жизни выполняются быстрее, не нащёлкаешься. Плюс, нужна некая накопительная асинхронность - прощёлкивать выполнение пару раз в день, сразу по пачке этапов. Неудобно оказалось через мобильное приложение, короче.
Ну, чё делать - поделил трудозатраты на двоих клиентов, сделали одинаковую обработку, выдали, привыкают. За индивидуальные особенности каждый сам заплатил отдельно.
Это - MES?
👍3
Вот чего подумал: это мой самый честный канал. Вот прям сложно тут писать, не приврёшь особо.
Знаете почему?
Потому что тут:
- 3 моих действующих клиента;
- человек 5, с которыми так или иначе что-то прорабатывали или обсуждаем;
- человек 10 моих сотрудников;
- несколько коллег из других отделов Бита;
- мой начальник.
Так что... Знак качества.
Знаете почему?
Потому что тут:
- 3 моих действующих клиента;
- человек 5, с которыми так или иначе что-то прорабатывали или обсуждаем;
- человек 10 моих сотрудников;
- несколько коллег из других отделов Бита;
- мой начальник.
Так что... Знак качества.
👍11😁11🔥3🤔1
Когда-то давно стал вести учёт работ своих программистов в разрезе конфигураций - мне это для управления и мотивации надо было. Иногда показываю заказчикам, внешним или внутренним, эти цифры.
А то ведь знаете - надо как-то отвечать на вопрос "А какой у вас опыт по УПП?". Вот, 10 317 часов.
Здесь опыт только текущего состава команды, уволившиеся исключены.
А то ведь знаете - надо как-то отвечать на вопрос "А какой у вас опыт по УПП?". Вот, 10 317 часов.
Здесь опыт только текущего состава команды, уволившиеся исключены.
🔥8
FlowconПроверкаДанных 202605071514.cfe
113.9 KB
Самое популярное моё решение, которому больше 10 лет. Знаменитая "Проверка данных", в виде расширения.
Статья с описанием тут - https://vk.com/@-208482299-proverka-dannyh
Видео с демонстрацией возможностей:
1. https://vk.com/video-208482299_456239478
2. https://vk.com/video-208482299_456239479
Статья с описанием тут - https://vk.com/@-208482299-proverka-dannyh
Видео с демонстрацией возможностей:
1. https://vk.com/video-208482299_456239478
2. https://vk.com/video-208482299_456239479
🔥10👍9
Решения, которые можно скачать:
1. Расширение "Проверка данных" - https://t.me/another1C/40
2. Расширение "Рабочий стол" - https://t.me/another1C/48
3. Конфигурация "Рабочий стол" - https://t.me/another1C/152
4. Отчёт "Структура затрат" - https://t.me/another1C/52
5. Расширение "Автозадачи" - https://t.me/another1C/81
6. Конфигурация "Универсальный механизм планирования" - https://t.me/another1C/92
7. Расширение "Универсальный механизм планирования" - https://t.me/another1C/130
8. Обработка "Статистика расширения" - https://t.me/another1C/148
9. Расширение "Информатор" - https://t.me/another1C/205
1. Расширение "Проверка данных" - https://t.me/another1C/40
2. Расширение "Рабочий стол" - https://t.me/another1C/48
3. Конфигурация "Рабочий стол" - https://t.me/another1C/152
4. Отчёт "Структура затрат" - https://t.me/another1C/52
5. Расширение "Автозадачи" - https://t.me/another1C/81
6. Конфигурация "Универсальный механизм планирования" - https://t.me/another1C/92
7. Расширение "Универсальный механизм планирования" - https://t.me/another1C/130
8. Обработка "Статистика расширения" - https://t.me/another1C/148
9. Расширение "Информатор" - https://t.me/another1C/205
🔥8👍6🙏1
Недавно была встреча с клиентом, который хотел MES. Думал, будет как обычно - грустно. Скажу "нет никакого MES на 1С", клиент расстроится, подумает что я вру и перестанет отвечать (обычно так и бывает). Но не тут-то было.
Начинаю говорить "вы знаете, MES на 1С...", а клиент "знаю, знаю, не работает, нет его". И рассказал, как посетил несколько предприятий (прям съездил!) в поисках работающего MES. Не нашёл. Судя по изменению тона беседы, моё уныние про MES послужило чем-то вроде пропуска доверия. Начал бы я "конечно, сделаем вам MES!" - попросили бы прислать КП, и на этом всё.
А тут вроде дальше продвинулись. Рассказал, что MES можно только сделать, своими руками. Собственно, MES-то я делал несколько раз, но обычно проблема - показать/доказать, это всегда доработка под конкретного клиента. Показывать решения без разрешения мне не позволит ни совесть, ни NDA, а спрашивать разрешения мне лень. Раньше пробовал - толку особо нет, начинается "нуууууу у нас-то всё сложнее/проще/по-другому, это не то, покажите предприятие нашего профиля".
Мой дружбан-начальник, который тоже был на встрече, предложил из моего старого доброго решения "Универсальный механизм планирования" сварганить демопример на данных или процессах клиента, тот пошёл их готовить. И ведь подготовил, прислал!
Так что, может и появится в этом мире MES от 1С.
Начинаю говорить "вы знаете, MES на 1С...", а клиент "знаю, знаю, не работает, нет его". И рассказал, как посетил несколько предприятий (прям съездил!) в поисках работающего MES. Не нашёл. Судя по изменению тона беседы, моё уныние про MES послужило чем-то вроде пропуска доверия. Начал бы я "конечно, сделаем вам MES!" - попросили бы прислать КП, и на этом всё.
А тут вроде дальше продвинулись. Рассказал, что MES можно только сделать, своими руками. Собственно, MES-то я делал несколько раз, но обычно проблема - показать/доказать, это всегда доработка под конкретного клиента. Показывать решения без разрешения мне не позволит ни совесть, ни NDA, а спрашивать разрешения мне лень. Раньше пробовал - толку особо нет, начинается "нуууууу у нас-то всё сложнее/проще/по-другому, это не то, покажите предприятие нашего профиля".
Мой дружбан-начальник, который тоже был на встрече, предложил из моего старого доброго решения "Универсальный механизм планирования" сварганить демопример на данных или процессах клиента, тот пошёл их готовить. И ведь подготовил, прислал!
Так что, может и появится в этом мире MES от 1С.
👍7
Расскажу о сопровождении, наверное в нескольких постах. Там, как мне кажется, интересна не столько текущая модель, сколько история появления и развития. Речь про сопровождении, которое у меня в отделе 101 делается.
Сопровождением мы называем работу с постоянными клиентами. Консультации, решение проблем, любая разработка, небольшие и большие проекты, которые нужны постоянным клиентам, участие в стратегии развития ИТ и т.д. Всё, что клиенту нужно.
Для начала - как было, да и сейчас устроено сопровождение в других местах, не буду их называть. Если вы - клиент, то, возможно, узнаете модель работы вашей обслуживающей организации.
Итак, обычно за клиентом закреплён один персонаж - менеджер. В его профиль компетенций не входит знание конфигураций, методической области, клиента, отрасли, бизнеса и т.д. Его задача - принимать задачи от клиента и искать на них исполнителя (программиста, аналитика или консультанта).
И есть несколько программистов, свободных радикалов, не привязанных ни к клиенту, ни к менеджеру.
Возникла у клиента задача - ошибка, месяц не закрывается, база тормозит, отчёт надо сделать, контур автоматизировать - клиент обращается к менеджеру. И тот - побежал. Ибо волка ноги кормят. В зависимости от менеджера и компании бежит он или к знакомым спецам, с которыми есть нормальные отношения, или к их начальнику (чтобы тот "выделил человека", система выделения начальников такое умеет 😁), а если связей нет - кидает задачу в какую-нибудь систему или письмом.
Ну а дальше - как повезёт. В прямом смысле, как лотерея.
Самый трагичный случай - это, увы, не редкость - исполнителя не получается найти вообще. Никто не берётся решать задачу, по разным причинам. Заняты, непонятная задача, неохота рисковать (не сделаешь - не заплатят), есть на выбор задачи попроще, менеджер "плохой" и т.д.
Если исполнитель находится, то, опять же, как у фокусника - "вытащите любую карту из колоды". Умеет ли он решать такие задачи, видел ли он эту конфигурацию, знаком ли с этим клиентом - узнать можно только в процессе и по результату. Грустных историй на эту тему - тысячи. Спец ковырялся-ковырялся, ничего не сделал и слился - вернул задачу менеджеру. Спец ковырялся-ковырялся, задачу так и не решил, признал её нерешаемой в принципе и посоветовал обратиться в 1С. Спец передал задачу другому спецу, и клиенту надо заново всё рассказывать и показывать.
Контролирует ли менеджер решение задач - зависит от человека. Большинство не контролируют. Точнее, бегут спрашивать у исполнителя, если клиент позвонит и спросит. Если у спеца возникают проблемы при решении задачи, никто особо ему не может помочь, потому что не обязан. Разве что у него много друзей, которым нечем заняться, но такое бывает редко. От менеджера толку или нет, или немного - нет ни нужных компетенций, ни влияния, ни полномочий. Разве что морально может поддержать, если человек хороший.
Наверное, пока хватит 😒
Продолжение следует.
Сопровождением мы называем работу с постоянными клиентами. Консультации, решение проблем, любая разработка, небольшие и большие проекты, которые нужны постоянным клиентам, участие в стратегии развития ИТ и т.д. Всё, что клиенту нужно.
Для начала - как было, да и сейчас устроено сопровождение в других местах, не буду их называть. Если вы - клиент, то, возможно, узнаете модель работы вашей обслуживающей организации.
Итак, обычно за клиентом закреплён один персонаж - менеджер. В его профиль компетенций не входит знание конфигураций, методической области, клиента, отрасли, бизнеса и т.д. Его задача - принимать задачи от клиента и искать на них исполнителя (программиста, аналитика или консультанта).
И есть несколько программистов, свободных радикалов, не привязанных ни к клиенту, ни к менеджеру.
Возникла у клиента задача - ошибка, месяц не закрывается, база тормозит, отчёт надо сделать, контур автоматизировать - клиент обращается к менеджеру. И тот - побежал. Ибо волка ноги кормят. В зависимости от менеджера и компании бежит он или к знакомым спецам, с которыми есть нормальные отношения, или к их начальнику (чтобы тот "выделил человека", система выделения начальников такое умеет 😁), а если связей нет - кидает задачу в какую-нибудь систему или письмом.
Ну а дальше - как повезёт. В прямом смысле, как лотерея.
Самый трагичный случай - это, увы, не редкость - исполнителя не получается найти вообще. Никто не берётся решать задачу, по разным причинам. Заняты, непонятная задача, неохота рисковать (не сделаешь - не заплатят), есть на выбор задачи попроще, менеджер "плохой" и т.д.
Если исполнитель находится, то, опять же, как у фокусника - "вытащите любую карту из колоды". Умеет ли он решать такие задачи, видел ли он эту конфигурацию, знаком ли с этим клиентом - узнать можно только в процессе и по результату. Грустных историй на эту тему - тысячи. Спец ковырялся-ковырялся, ничего не сделал и слился - вернул задачу менеджеру. Спец ковырялся-ковырялся, задачу так и не решил, признал её нерешаемой в принципе и посоветовал обратиться в 1С. Спец передал задачу другому спецу, и клиенту надо заново всё рассказывать и показывать.
Контролирует ли менеджер решение задач - зависит от человека. Большинство не контролируют. Точнее, бегут спрашивать у исполнителя, если клиент позвонит и спросит. Если у спеца возникают проблемы при решении задачи, никто особо ему не может помочь, потому что не обязан. Разве что у него много друзей, которым нечем заняться, но такое бывает редко. От менеджера толку или нет, или немного - нет ни нужных компетенций, ни влияния, ни полномочий. Разве что морально может поддержать, если человек хороший.
Наверное, пока хватит 😒
Продолжение следует.
👍7🔥4
Продолжаю про сопровождение, как мы решали проблемы этого процесса.
Для начала взялись за поиск исполнителя. Раньше этим занимался менеджер - бегал, спрашивал, разговаривал, уговаривал, требовал и т.д.
Любой глагол, лишь бы задачу пристроить и забыть про неё. Как с горячей картошкой носился, которую хотелось побыстрее скинуть.
Решение лежало на поверхности - пусть не менеджер ищет программиста, а руководитель программистов. Менеджер куда-то скидывает задачу (они любят "скидывать", это ж обезьяну с шеи снять), руководитель программистов (тогда это был я) смотрит и решает, кто её будет делать. Исходя из навыков, текущей загрузки, срочности/важности задачи и т.д.
Удалось избежать такой дичи, как "давайте создадим Систему" - мол, ты конечно молодец, придумал что руководитель будет распределять задачи, но нужна Система, в которой Всё Будет Прозрачно. Вообще, дичь в данном случае - не сама система, а телега впереди лошади, когда сначала надо сделать систему, а потом менять процесс в жизни.
В качестве "Системы" вполне сгодился чат в телеге, куда я добавил всех менеджеров и программистов. На "разработку системы" ушла 1 минута. Написал короткие правила и в тот же день началось распределение задач. Назвал чат, разумеется, "Свободная касса". Менеджеров было человек 10-15 (точно не помню, дело было в 2019 году), программистов - человек 6-8 вместе со мной.
Менеджеры просто писали задачи, я иногда пару вопросов задавал, и назначал исполнителя. На этом для менеджера история, в целом, заканчивалась. Несложно догадаться, что большинство менеджеров сразу стали фанатами и чата, и нашей команды. Я даже статистику подсчитывал: до появления "кассы", в среднем, на распределение задачи уходило несколько часов, до недели, теперь же - минуты.
Это было только начало, разумеется. Дальше расскажу остальное.
Но тележные чаты, как инструмент оперативного распределения задач сопровождения, жив и здоров до сих пор.
Для начала взялись за поиск исполнителя. Раньше этим занимался менеджер - бегал, спрашивал, разговаривал, уговаривал, требовал и т.д.
Любой глагол, лишь бы задачу пристроить и забыть про неё. Как с горячей картошкой носился, которую хотелось побыстрее скинуть.
Решение лежало на поверхности - пусть не менеджер ищет программиста, а руководитель программистов. Менеджер куда-то скидывает задачу (они любят "скидывать", это ж обезьяну с шеи снять), руководитель программистов (тогда это был я) смотрит и решает, кто её будет делать. Исходя из навыков, текущей загрузки, срочности/важности задачи и т.д.
Удалось избежать такой дичи, как "давайте создадим Систему" - мол, ты конечно молодец, придумал что руководитель будет распределять задачи, но нужна Система, в которой Всё Будет Прозрачно. Вообще, дичь в данном случае - не сама система, а телега впереди лошади, когда сначала надо сделать систему, а потом менять процесс в жизни.
В качестве "Системы" вполне сгодился чат в телеге, куда я добавил всех менеджеров и программистов. На "разработку системы" ушла 1 минута. Написал короткие правила и в тот же день началось распределение задач. Назвал чат, разумеется, "Свободная касса". Менеджеров было человек 10-15 (точно не помню, дело было в 2019 году), программистов - человек 6-8 вместе со мной.
Менеджеры просто писали задачи, я иногда пару вопросов задавал, и назначал исполнителя. На этом для менеджера история, в целом, заканчивалась. Несложно догадаться, что большинство менеджеров сразу стали фанатами и чата, и нашей команды. Я даже статистику подсчитывал: до появления "кассы", в среднем, на распределение задачи уходило несколько часов, до недели, теперь же - минуты.
Это было только начало, разумеется. Дальше расскажу остальное.
Но тележные чаты, как инструмент оперативного распределения задач сопровождения, жив и здоров до сих пор.
🔥14👍1🗿1
Вообще, я не люблю официальные отзывы, которые публикуют по результатам проектов. Мы с вами - люди взрослые, и знаем, что никакой особой связи между отзывом и реальностью нет. Разве что какая была внедрена конфигурация и сколько продано автоматизировано рабочих мест. Поэтому отзывы не пишу.
Но коллеги пишут, и иногда - по проектам, где участвовали мои программисты из отдела 101.
Один отзыв особенно запомнился. Во-первых, он на одном из сайтов Сбера. Во-вторых, весь проект занял два трудодня 😁.
У клиента была старая УТ 11, он хотел купить Бит.Финанс, но сомневался, что на старой конфигурации будет работать. Соответственно, не мог решить, покупать или нет. Релизов для такой старой УТ 11 не было - во времена выхода релиза клиента ещё не было сборки Бит.Финанса для УТ 11, её то ли ещё делали, то ли собирались.
Менеджеры не смогли убедить клиента, что всё будет хорошо, только счёт оплати. Я предложил так: клиент даёт свою конфигурацию, мы на свой страх и риск, за свой счёт, впихиваем туда Бит.Финанс, устраняем неизбежные ошибки совместимости, а если всё получится - клиент покупает коробку и оплачивает работы по объединению конфигураций.
Посадил толкового программиста, который не боится трудностей. На всё про всё ушёл 1 день - конфигурацию изготовили. Клиенту сказали, что можно пробовать на копии (у нас была только конфигурация, без данных). Клиент дал доступ к копии, накатили, ещё пара ошибок вылезла, всё убрали и показали клиенту. Те с радостью оплатили счёт на Бит.Финанс и 10 часов работы программиста.
Это был первый трудодень проекта.
Второй случился через некоторое время. Клиент, обрадованный наличием Бит.Финанса, побежал настраивать бюджеты, но столкнулся с трудностями - что-то не получалось. Не ошибки повылезали, а именно в типовой настройке не мог детально разобраться, что-то не получалось.
Клиент пошёл к менеджерам, те подключили аналитиков по Бит.Финансу - очень серьёзных ребят, к которым на хромой кобыле не подъедешь. Естественно, клиенту предложили Проект по внедрению Бит.Финанса, чем повергли его в смутные сомнения.
Какими-то окольными путями ситуация дошла до нас, программистов. Я говорю - у клиента толковые люди сидят, им не нужен Проект, им надо помочь решить конкретные вопросы. Подсказать, показать, поднастроить. Предложил того же толкового программиста, который изготавливал конфигурацию. Клиент согласился, а серьёзные люди-аналитики обиделись, наверное.
Итого, на всю помощь клиенту с его вопросами, мелкими настройками, отладкой, проверкой и т.д. ушло ещё 9 часов работы программиста. Это был второй трудодень проекта.
Собственно, всё 🤦♀️
P.S. А теперь сравните мой рассказ с текстом отзыва 🙈
https://sber.pro/digital/publication/konfeti-i-finansi-kak-produktovii-distribyutor-tsifroviziroval-byudzhetnie-protsessi/
Но коллеги пишут, и иногда - по проектам, где участвовали мои программисты из отдела 101.
Один отзыв особенно запомнился. Во-первых, он на одном из сайтов Сбера. Во-вторых, весь проект занял два трудодня 😁.
У клиента была старая УТ 11, он хотел купить Бит.Финанс, но сомневался, что на старой конфигурации будет работать. Соответственно, не мог решить, покупать или нет. Релизов для такой старой УТ 11 не было - во времена выхода релиза клиента ещё не было сборки Бит.Финанса для УТ 11, её то ли ещё делали, то ли собирались.
Менеджеры не смогли убедить клиента, что всё будет хорошо, только счёт оплати. Я предложил так: клиент даёт свою конфигурацию, мы на свой страх и риск, за свой счёт, впихиваем туда Бит.Финанс, устраняем неизбежные ошибки совместимости, а если всё получится - клиент покупает коробку и оплачивает работы по объединению конфигураций.
Посадил толкового программиста, который не боится трудностей. На всё про всё ушёл 1 день - конфигурацию изготовили. Клиенту сказали, что можно пробовать на копии (у нас была только конфигурация, без данных). Клиент дал доступ к копии, накатили, ещё пара ошибок вылезла, всё убрали и показали клиенту. Те с радостью оплатили счёт на Бит.Финанс и 10 часов работы программиста.
Это был первый трудодень проекта.
Второй случился через некоторое время. Клиент, обрадованный наличием Бит.Финанса, побежал настраивать бюджеты, но столкнулся с трудностями - что-то не получалось. Не ошибки повылезали, а именно в типовой настройке не мог детально разобраться, что-то не получалось.
Клиент пошёл к менеджерам, те подключили аналитиков по Бит.Финансу - очень серьёзных ребят, к которым на хромой кобыле не подъедешь. Естественно, клиенту предложили Проект по внедрению Бит.Финанса, чем повергли его в смутные сомнения.
Какими-то окольными путями ситуация дошла до нас, программистов. Я говорю - у клиента толковые люди сидят, им не нужен Проект, им надо помочь решить конкретные вопросы. Подсказать, показать, поднастроить. Предложил того же толкового программиста, который изготавливал конфигурацию. Клиент согласился, а серьёзные люди-аналитики обиделись, наверное.
Итого, на всю помощь клиенту с его вопросами, мелкими настройками, отладкой, проверкой и т.д. ушло ещё 9 часов работы программиста. Это был второй трудодень проекта.
Собственно, всё 🤦♀️
P.S. А теперь сравните мой рассказ с текстом отзыва 🙈
https://sber.pro/digital/publication/konfeti-i-finansi-kak-produktovii-distribyutor-tsifroviziroval-byudzhetnie-protsessi/
СберПро | Медиа
Конфеты и финансы. Как продуктовый дистрибьютор цифровизировал бюджетные процессы | СберПро Медиа
До 20 раз сократилось время бюджетного планирования после автоматизации
🔥5👍2🤨1
Другой 1С
Меня тут на работе отругали, что я мало во встречах участвую. Что правда, то правда - за годы работы в Бите я проигнорировал, отказался или пропустил огромное количество встреч. Особенно по видеосвязи - почему-то у меня долго было стойкое отторжение к этому…
Решил повторить акцию с бесплатными встречами. В прошлый раз было и интересно, и полезно.
Поговорил тогда и с конкурентами (обменялись опытом, без купюр), и с парнями с больших заводов, и с совершенно неожиданными людьми из по-настоящему крупных ИТ-компаний, и со старыми знакомыми.
Был и чисто деловой выхлоп - два новых клиента на сопровождении, с потенциалом на большие, средние и малые проекты. Работаем 3 месяца, успели немного поругаться, сделать перестановки в команде и опять всё наладить. Продолжаем работать.
Ещё одна причина, почему решил повторить - время появилось. Я в мае отдал хорошим людям пару своих обязанностей, которые отнимали время и держали в напряжении. Могу снова смотреть на мир открытыми весёлыми глазами.
Если хотите со мной бесплатно поговорить - добро пожаловать. Пишите на nmivan@mail.ru, договоримся о времени и дате.
В письме в двух словах черкните, о чём хотите поговорить и кто вы по должности.
Обещаю не вносить вашу почту ни в какую базу.
Поговорил тогда и с конкурентами (обменялись опытом, без купюр), и с парнями с больших заводов, и с совершенно неожиданными людьми из по-настоящему крупных ИТ-компаний, и со старыми знакомыми.
Был и чисто деловой выхлоп - два новых клиента на сопровождении, с потенциалом на большие, средние и малые проекты. Работаем 3 месяца, успели немного поругаться, сделать перестановки в команде и опять всё наладить. Продолжаем работать.
Ещё одна причина, почему решил повторить - время появилось. Я в мае отдал хорошим людям пару своих обязанностей, которые отнимали время и держали в напряжении. Могу снова смотреть на мир открытыми весёлыми глазами.
Если хотите со мной бесплатно поговорить - добро пожаловать. Пишите на nmivan@mail.ru, договоримся о времени и дате.
В письме в двух словах черкните, о чём хотите поговорить и кто вы по должности.
Обещаю не вносить вашу почту ни в какую базу.
🔥9👍1
FlowconРабочийСтол 202601311816.cfe
145.6 KB
Второе бесплатное решение - старый добрый "Рабочий стол", в виде расширения. Можете брать и пользоваться.
Понадобится помощь программистов - пишите, мои люди по нему экзамен сдают.
Почитать про "Рабочий стол" можно здесь - https://infostart.ru/marketplace/957530/
Видео:
1. https://vkvideo.ru/video-208482299_456239487
2. https://vkvideo.ru/video-208482299_456239491
3. https://vkvideo.ru/video-208482299_456239497?list=ln-BKsiW5Xfu9tyPmSipy
Понадобится помощь программистов - пишите, мои люди по нему экзамен сдают.
Почитать про "Рабочий стол" можно здесь - https://infostart.ru/marketplace/957530/
Видео:
1. https://vkvideo.ru/video-208482299_456239487
2. https://vkvideo.ru/video-208482299_456239491
3. https://vkvideo.ru/video-208482299_456239497?list=ln-BKsiW5Xfu9tyPmSipy
🔥13👍6❤🔥2
Так, у меня тут небольшой левел ап - с мая в моём отделе проектов 101 появились менеджеры по продажам.
Я в Бите 5 лет работаю, всё это время в периметре были только программисты, иногда - аналитики. Продавцы всегда были из других отделов, мы с ними сотрудничали, как-то вместе пытались организовывать работу с клиентом. Не всегда удачно, увы.
Ну, оно и понятно. Каждый отдел - это чьё-то племя, со своими целями, стратегией, процессами и правилами. Кроссфункциональное взаимодействие - всегда риск.
Так что теперь у нас полный цикл по 1С - от продажи ПО/лицензий до экспертных работ. Всё в одном месте.
Захотите купить коробочку - обращайтесь.
Ещё учебный центр открыли, но он пока только внутри Бита работает, так что просто порадуйтесь за нас 😁
Я в Бите 5 лет работаю, всё это время в периметре были только программисты, иногда - аналитики. Продавцы всегда были из других отделов, мы с ними сотрудничали, как-то вместе пытались организовывать работу с клиентом. Не всегда удачно, увы.
Ну, оно и понятно. Каждый отдел - это чьё-то племя, со своими целями, стратегией, процессами и правилами. Кроссфункциональное взаимодействие - всегда риск.
Так что теперь у нас полный цикл по 1С - от продажи ПО/лицензий до экспертных работ. Всё в одном месте.
Захотите купить коробочку - обращайтесь.
Ещё учебный центр открыли, но он пока только внутри Бита работает, так что просто порадуйтесь за нас 😁
👍9👏4🎉3❤1
Про сопровождение продолжу. В прошлый раз рассказал про чаты, где задачи стали распределяться.
Дальше вылезла проблема, знакомая, наверное, большинству клиентов франчей - смена спецов.
Если задачи у клиента возникают нерегулярно, или, точнее, между задачами есть перерывы, то на каждую новую задачу назначают... Никогда не знаешь, кого. То знакомый спец попадётся, то - совершеннейшее инкогнито.
Я сейчас не буду говорить про компетенции спеца, которого назначают на задачу. Хотя, почему не буду... Если задачу изначально "снимает" менеджер, особенно молодой, то вероятность ошибки при выборе спеца очень велика. Например, клиент скажет "надо поднастроить отчёт по складу" - а там окажется запуск резервирования. Или задача "база тормозит" может оказаться начало мини-проекта по рефакторингу доработок. И т.д.
Но я не про это сейчас. Проблема в том, что спец - новый. Он не знает, как подключиться. Где база рабочая, а где - копия. Можно ли в этой копии трогать документы, или там другой спец что-то моделирует. Есть ли хранилище конфигурации. Кто и как обновляет рабочую базу. Не говоря уж про тысячи особенностей в системе клиента, известных только... Никому не известных, потому что спецы регулярно меняются.
У нас была такая же проблема. Точнее, у наших клиентов. Везло тем, кто сыпал задачами, как из рога изобилия, и мог загрузить какого-нибудь спеца хотя бы на полмесяца - можно было закрепить программиста за клиентом. Но, повторюсь, это работало только при достаточно большом объёме задач. Если загрузки мало, спец сам переключался на других клиентов - ему ж надо деньги зарабатывать. А когда у закреплённого клиента возникала срочная задача, спец оказывался занят. Обиды, звонки, ругань, "дайте другого", там новый, и всё по кругу.
Что делать?
Решение было простое, как дрова. Я ж ИТ-директором раньше работал, на заводе. Там модель понятная: есть ИТ-отдел, в нём программисты, они должны решать все задачи, у них нет вариантов. И они знают всё и всех - людей, инфраструктуру, процессы, особенности, порядок обновления и т.д. Всё, что нужно для решения задач.
Почему бы не использовать этот опыт во франче? Вот есть у меня небольшая команда, человек 5 - пусть все эти 5 человек знают всё про каждого постоянного клиента. Пусть все с ним поработают, познакомятся. Пусть они после каждой решённой задачи кратко расскажут остальным, что и как делали, в чём и у кого была проблема, как решили. Пусть по каждому клиенту будет понятная, согласованная схема внесения изменений в рабочую базу, и все 5 человек её знают.
Так и появилась идея командного сопровождения. Закреплять за клиентом не одного спеца, а целую команду. Чтобы в случае срочной проблемы или задачи всегда был выбор, кого подключить. А если задача, не срочная - кому поставить в очередь на решение.
Согласитесь, просто. Потому и заработало быстро.
Дальше вылезла проблема, знакомая, наверное, большинству клиентов франчей - смена спецов.
Если задачи у клиента возникают нерегулярно, или, точнее, между задачами есть перерывы, то на каждую новую задачу назначают... Никогда не знаешь, кого. То знакомый спец попадётся, то - совершеннейшее инкогнито.
Я сейчас не буду говорить про компетенции спеца, которого назначают на задачу. Хотя, почему не буду... Если задачу изначально "снимает" менеджер, особенно молодой, то вероятность ошибки при выборе спеца очень велика. Например, клиент скажет "надо поднастроить отчёт по складу" - а там окажется запуск резервирования. Или задача "база тормозит" может оказаться начало мини-проекта по рефакторингу доработок. И т.д.
Но я не про это сейчас. Проблема в том, что спец - новый. Он не знает, как подключиться. Где база рабочая, а где - копия. Можно ли в этой копии трогать документы, или там другой спец что-то моделирует. Есть ли хранилище конфигурации. Кто и как обновляет рабочую базу. Не говоря уж про тысячи особенностей в системе клиента, известных только... Никому не известных, потому что спецы регулярно меняются.
У нас была такая же проблема. Точнее, у наших клиентов. Везло тем, кто сыпал задачами, как из рога изобилия, и мог загрузить какого-нибудь спеца хотя бы на полмесяца - можно было закрепить программиста за клиентом. Но, повторюсь, это работало только при достаточно большом объёме задач. Если загрузки мало, спец сам переключался на других клиентов - ему ж надо деньги зарабатывать. А когда у закреплённого клиента возникала срочная задача, спец оказывался занят. Обиды, звонки, ругань, "дайте другого", там новый, и всё по кругу.
Что делать?
Решение было простое, как дрова. Я ж ИТ-директором раньше работал, на заводе. Там модель понятная: есть ИТ-отдел, в нём программисты, они должны решать все задачи, у них нет вариантов. И они знают всё и всех - людей, инфраструктуру, процессы, особенности, порядок обновления и т.д. Всё, что нужно для решения задач.
Почему бы не использовать этот опыт во франче? Вот есть у меня небольшая команда, человек 5 - пусть все эти 5 человек знают всё про каждого постоянного клиента. Пусть все с ним поработают, познакомятся. Пусть они после каждой решённой задачи кратко расскажут остальным, что и как делали, в чём и у кого была проблема, как решили. Пусть по каждому клиенту будет понятная, согласованная схема внесения изменений в рабочую базу, и все 5 человек её знают.
Так и появилась идея командного сопровождения. Закреплять за клиентом не одного спеца, а целую команду. Чтобы в случае срочной проблемы или задачи всегда был выбор, кого подключить. А если задача, не срочная - кому поставить в очередь на решение.
Согласитесь, просто. Потому и заработало быстро.
🔥15👍2💯1