Надо как-нибудь устроить конференцию по теме "Стратегический ИТ-тупик: "ещё рано" против "уже поздно"".
"Ещё рано" - клиенты, которые вступают на путь, ведущий в стратегический тупик.
"Уже поздно" - клиенты, которые уже в тупике, осознают его и пытаются выбраться.

Зачем конференция - чтобы они встретились и поговорили. Кажется, они никогда друг друга не видели.

Потому что мне клиенты верят далеко не всегда. Бывает, в течение дня я поговорю и с теми, и с другими. С утра - люди, ищущие выход из тупика. Ближе к вечеру - те, кто собирается в него попасть, но пока не этого не понимает. Говоришь им - "блин, вот только утром разговаривал с теми, кто однажды пошёл этим путём, и теперь вынужден потратить миллионы рублей на выход, ну поверьте мне, пожалуйста, не идите туда". Не, не верят.

А друг другу наверняка поверят.

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

А теперь смогут сказать "покажите мне схожее по профилю и масштабу предприятие, которое пошло тем же путём и зашло в тупик". Хотя, наверное, вряд ли кто-то захочет рассказывать о своих ошибках... Это же немножко вроде как позорище. Собственнику, директору, может, и нормально об ошибках рассказывать, а вот ИТ-директору или программисту - ни-ни. Репутация, резюме. Вдруг потом придёшь на собеседование к тем, перед кем эмоциональный стриптиз устраивал.

Как думаете, интересно ли такие "кейсы наоборот", антикейсы читать?

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

А на этих программистах, допустим, всё по 1С завязано - и поддержка, и развитие. Ладно развитие, его можно в случае чего приостановить. А сопровождение? А если система не типовая, и критичность высокая? У знакомого ровно такая ситуация.

Он думал про документирование, я предложил диверсификацию в двух вариантах.

Первый - добавить 1-2 стажёров, пусть сидят и учатся, занимаясь в основном сопровождением. И недорого, и найти проще, и старые немного меньше нос задирать будут.

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

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

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


Ну ничё, уже пятый год сопровождаем. Постоянная команда на данный момент - 5 человек. На подхвате, в случае необходимости - ещё столько же. Раньше работали с этим же клиентом, и всё помнят - ещё человек 5.

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

15 программистов в доступе по цене одного. Так, что ли, получается 😁

Был недавно на встрече с клиентом - коллеги из другого офиса позвали поучаствовать, ибо УПП. Причем, клиент не хотел никуда с УПП переходить - ему всё нравилось, хоть оно и не работало, как задумано 😁.

И директор клиента, один из идеологов доработок УПП, каааааак скажет: вы нас ни с кем не сравнивайте, у нас уникальные процессы, уникальное производство и вообще уникальное всё (я ему рассказывал, что есть два почти таких же клиента).

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

Так вот, я говорю директору: зря вы так. Вот сказали, что уникальные - и сразу х2, а то и х3 к сумме. А спросите потом, чё так дорого - скажут "так вы ж уникальные, вам шаблонные решения не подойдут". И слова назад не возьмёте, вы ж директор.

Не уверен, что он меня понял. Поэтому вам вот написал.

Продолжим про сопровождение, которое мы тут выстраивали. Предыдущий пост тут.

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

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

Например, мы работаем до 18:00, а клиент - до 21:00, или круглосуточно. Не часто, но случается какая-нибудь фигня, требующая внимания программиста. Ещё разница во времени играет роль - география клиентов и их филиалов может быть очень обширной.

Всем клиентам, опять же, рано или поздно нужно рабочую базу обновлять - релиз накатывать или изменения вносить. Если это ЗУП на 2 пользователей - ладно, можно днём. А если ERP или УПП на 100+ человек? Выгнать днём можно только в критической ситуации.

Ну и банально: некоторые программисты предпочитают работать в нерабочее время. Я, например. И не я один такой. Некоторые просто хотят иногда побольше заработать, и фигачат по 12 часов в день.

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

Думали-думали, целый час, и решили за нерабочее время брать, как за рабочее. Коллеги/смежники говорили, что теперь у нас не будет ни выходных, ни сна, ни отпусков. Не сбылись прогнозы - всё хорошо.

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

Видео вам снял.
Про то, как выбирать отраслевые решения 1С.

https://youtu.be/5fyRks28SUI

Кто из Челябинска, тут мероприятие 1С организовала, про ЕРП, 11 сентября.
Бесплатно для руководящего состава предприятий.
Если кто желает быть приглашённым 😁 - черкните в личку @Ivan_Belokamentsev, повелю моим любимым менеджерам с вами связаться и пригласить.

https://1c.ru/news/info.jsp?id=31941

Видео вам снял - https://youtu.be/sJS-BsZvw-U

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

Но я не об этом. В прошлом году они обращались с жуткой проблемой - себестоимость в ЕРП считалась двое суток. Я тогда поковырялся, нашёл узкое место в архитектуре типовой конфигурации, сделал прототип решения, себестоимость стала считаться в 6-8 раз быстрее. Кратко описал кейс в канале для программистов и забыл. Почему забыл: клиенту не нужно было решение "под ключ", т.к. есть свои программисты - нужен был прототип, прорыв, чтобы сдвинуть проблему с места, а дальше они сами.

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

Приятно.

Видео вам снял, вторую серию про экономию на проектах перехода.
https://youtu.be/57KBrDUi-wc

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

Видео вам снял - https://youtu.be/XvdMYRcyKlE

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

В 2005-2009 г., в первом моём франче, была простая формула расчёта бесплатных часов, я её вспомнил, осовременил, и тоже решил попробовать.
В июле сказал знакомым клиентам - ну, на случай, вдруг они собирались что-нибудь купить. Тут же нашлись желающие купить ЕРП и КА2 ("раз такое дело").

Ну и раз такое дело, решил вам тоже предложить эту акцию: за каждые 10 000 р. стоимости ПО/лицензий, которые у нас купите, получите 1 час работы программиста бесплатно. Например, берёте коробку за 600 т.р. - получаете 60 бесплатных часов.
Предложение, скорее всего, ограничено будет, по времени или суммарной реализации - не хочу в большие "долги" влезать, программисты нормально загружены обычной, платной работой.

Прелесть в том, что и менеджеры, которые продают ПО и лицензии, и программисты, которые будут эти бесплатные часы отрабатывать - в моём отделе. Это значит, что не будет традиционных конфликтов между продавцом бесплатных часов и теми, кто их должен потом "отрабатывать".

В этой прелести, правда, и ограничение:
1. Купить надо именно в моём отделе, у моих менеджеров.
Это не акция всего Бита или нашего Челябинского офиса.
2. Отрабатывать бесплатные часы будут именно мои программисты, не какие-то соседние.
Программистов у меня всего 30, на всех не хватит, поэтому я и написал выше про ограниченность акции.

Надумаете - пишите мне (@Ivan_Belokamentsev).

Запустили в работу ещё 2 проекта перехода УПП-ЕРП по экспертной технологии (которые за 1-1.5 тыс. часов). Теперь в работе 5 таких проектов (один не про ЕРП, а про Аренду, но тоже из УПП).
Срок запуска у обоих проектов - 26 год, так что на исполнение 1.5 года. Месячный объём работ - даже одного программиста не загружает.
На каждом проекте, по сути - один программист и один эксперт. На трёх проектах экспертом числюсь я.

Сказал менеджерам больше не говорить клиентам, что переход с УПП на ЕРП можно сделать за 4-5 млн. рублей 😁
Никто же больше не говорит, чё мы одни, как дураки.

Раз такое дело с ютубом, продублировал видео на другие платформы.
Перенос ещё идёт, но вступать/подписываться уже можно:

https://rutube.ru/u/nmivan/
https://vk.com/video/@ivan.belokamentsev

Так, я ж про сопровождение не всё рассказал. В прошлый раз было про оплату в нерабочее время по обычной ставке.
Итак, у нас есть команда из нескольких человек, закреплённая за клиентом, есть продюсер (главный по клиенту), где-то на бэкграунде есть менеджер.

Очень быстро наткнулись на ожидаемую проблему - от клиента пришла задача, которую не могла решить назначенная команда. Ну т.е. как не могла... Могла, конечно. Я всегда программистам говорю - вы можете решить любую задачу, вопрос лишь в требуемом количестве времени. Это так, для мотивации, чтобы забыли слово "невозможно" :)

Так вот, мы реалисты, и понимаем - у любого клиента может случиться сложная задача. Сложная по комбинации факторов, один из которых, обычно - срочность. Хотя, бывает и не срочно. Что делать?

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

Обычно эксперт всегда занят. Его грузят в первую очередь, потому что он стоит дорого. Он не может и не должен простаивать. Чем же его грузят? По уму, это должны быть какие-то экспертные работы - что-то эдакое, где абы кто не справится. Но чтобы на полный день загрузить эксперта такой работой, нужно стадо менеджеров. Парадокс, но... Экспертные работы клиентам нужны редко. Ну, нет у них столько сложных и страшных проблем. Наверное, можно считать это комплиментом 1С. Или срочности у проблем нет.

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

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

Главное - чтобы он был в доступе, когда потребуется. Чтобы ждать его не надо было.
Сломалась база, команда не справляется известными ей методами - зовём эксперта, он сразу приходит. И починить поможет, и команда что-то новое узнает.
Надо принять сложное архитектурное решение - позвали эксперта, за 10 минут объяснили ситуацию, он 10 минут подумал, 10 минут поговорил - решение принято, за полчаса.

И самое удивительное - сколько в реальности нужно экспертов, чтобы поддерживать такую схему. У меня в отделе их всего два, а программистов - 30. И не сказать, что эксперты перерабатывают. Один из них успевает всем отделом управлять, продавать, программировать и всякую фигню в интернете писать про использование экспертов :)

Да, чуть не забыл. За помощь эксперта программистам клиент ничего не платит. Пару лет мы закладывали доплату за эксперта в часовую ставку, объясняя смысл клиентам и предоставляя право выбрать (с экспертом или без). Разница была рублей 200 вроде, 8% тогдашней ставки.

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

Один старый клиент обновил начал работать в УНФ - у него розничная сеть, которая работала на 1С:Рознице. Оказалось, с Розницы на УНФ можно просто обновиться.

В УНФ работать страшно, когда что-то более или менее серьёзное требуется. Не потому, что в УНФ чего-то нет - как раз наоборот.

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

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

Из последнего: обмен с ЗУП. Клиент видит, что обмен в конфигурации присутствует, настраивает - а там почти никакие данные не ходят.

Читаем мнение разработчиков - а они не собирались "развивать" обмен с ЗУП (нафига тогда создавали "недоразвитый" обмен?). Потом читаем - ага, полгода назад передумали, начали развивать. Обновляем - стало получше, данных ходит больше, но...

Но мы не можем получить в УНФ хотя бы расходы по зарплате из ЗУПа. Потому что отражение зарплаты из ЗУПа приходит, но не делает никаких движений в регистрах 😁. А документ начисления зарплаты, который делает движения, не участвует в обмене 😂.

И это не в первый раз. До того был баланс, НДС в запасах, что-то ещё.

Так-то можно доработать, без проблем. Но когда клиенты покупают УНФ, они не планировали тратить кучу денег на доработки, особенно нацеленные на "просто чтобы работало".

В ЕРП такое тоже есть, но в менее востребованных кусках, вроде планирования. Уж отражение расходов по зарплате-то там работает.

Когда работал ИТ-директором, случалось заниматься настоящей автоматизацией, когда цель - как минимум освободить у сотрудников значительное количество времени. А в идеале - чтобы эти сотрудники стали не нужны. Кровожадно немного, конечно, но если разобраться, исходная цель автоматизации именно в этом.

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

Один раз за 5 лет была такая задача, но быстро отменилась (людей просто припугнуть хотел директор, они всё поняли и "исправились").

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

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

Если вы занимаетесь автоматизацией, то скажите честно – много ли людей были освобождены от обязанностей благодаря вашей работе? Только здесь важны факты, а не домыслы.

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

https://infostart.ru/pm/1017534/

Акция ещё действует, за сентябрь отгрузили примерно 60 бесплатных часов, столько же висит пока неиспользованных клиентами.
За неделю октября ещё 12 бесплатных часов начислили - клиент купил лицензии.

Если верить результатам опроса, у нас тут, в основном, собрались просто хорошие люди 😏
Ну и конкуренты.
Штош, буду учитывать при выборе тем.

На случай, если вы ещё не используете "Проверку данных", я пару примеров применения напишу. И суть идеи.
Суть идеи: не программировать каждую мелкую, "глупую" проверку, привязанную к конкретным данным клиента.

Например, у вас есть номенклатура, которую вы больше не используете - вывели из оборота, поставщик пропал, перешли на аналог и т.д.
Вы её или на удаление помечаете, или в отдельную папку складываете, или "НЕ ИСПОЛЬЗОВАТЬ" дописываете в названии.
Как запретить пользователям указывать её, например, в заказах? Типовых средств нет. Программист может сделать, но это минимум 1 час работы, включая обновление базы. Ещё и ругаться будет, что в коде приходится обращаться к конкретной папке номенклатуры.

А в "Проверке данных" вы это сделаете минут за 5-10 без программирования. Просто укажете документ, и сделаете отбор, как в отчётах (типа "Номенклатуре Не в группе Удаленные). И всё.

Или вот хотите вы, чтобы пользователь в УПП в номенклатуре всегда указывал номенклатурную группу - для вас это важно, она используется в отчётах. А УПП позволяет не заполнять. Программист-то справится, через конфигуратор.
И "Проверка данных справится", только минут за 5 и без программирования.
Если заменить УПП на ЕРП, а номенклатурную группу на ГФУ - ответ будет тем же.

Чуть сложнее: хотите вы, чтобы указывали в номенклатуре артикул. Но не во всей, а только в папке "Товары". Тоже в проверку данных, тоже минут на 5.

Ну, вы поняли. Уровень сложности использования "Проверки данных" - как отбор в отчёте настроить. А мелких хотелок задёшево реализует - не сосчитать.