Гипновброс с тренингов.png
1011.4 KB
Всегда волнительно возвращаться после длительного отсутствия в блоге.
Что происходило в это время?
Активно развивали направление обучения цифровой сознательности:
- по 2 потока корпоративных тренингов «автоматизация декларирования с развитием цифровой сознательности» (больше двух потоков параллельно пока не получается вести с сохранением качества обучения и динамики реализации проектной задачи)
- тренинги по развитию цифровой сознательности в различных функциональных направления (для логистов, для руководителей)
И да, скрин выше – это из реально презентации из тренинга. Я умею совместить полезную пользу с живой подачей. И даже «очень серьезным офисным руководителям» такой подход ближе, чем «с серьезным лицом рассказывать о серьезных серьезностях, пока все слушатели похрапывают на галерке».
Попутно продолжали текущие проекты (битриксы-шмитриксы, автоматизации, отчетности, дашборды и т.д.), решали задачи компаний, находящихся на сопровождении.
И вот в этом всем, как-то до блога руки не доходили. А постить «нейронный контент» не хотелось. Им и так сейчас все злоупотребляют.
Но есть очень важная вещь, которой хочется поделиться. Пока проводили тренинги, пришла идея провести открытый вебинар про то, как цифровая сознательность позволяет экономить деньги.
Один из наиболее частых вопросов он про «а где тут деньги и профиты». И правда, бизнес он же про деньги, а не про «оптимизацию ради оптимизации, и чтобы скучно не было». Да и сотрудники в общем тоже про деньги. «А оно мне зачем эта ваша цифровая сознательность. Сижу себе работаю, как учили. Не мешаю никому».
Но ровно в тот момент, когда бизнес начинает понимать, а где тут деньги, а сотрудник видит потенциал своего роста в деньгах, в этот момент отношение ко всему меняется.
Вот как раз об этом и поговорим 18.08.2023 в 10.00. 👉Жмакай, чтобы зарегистрироваться👈 Вебинар будет о серьезном.
Что происходило в это время?
Активно развивали направление обучения цифровой сознательности:
- по 2 потока корпоративных тренингов «автоматизация декларирования с развитием цифровой сознательности» (больше двух потоков параллельно пока не получается вести с сохранением качества обучения и динамики реализации проектной задачи)
- тренинги по развитию цифровой сознательности в различных функциональных направления (для логистов, для руководителей)
И да, скрин выше – это из реально презентации из тренинга. Я умею совместить полезную пользу с живой подачей. И даже «очень серьезным офисным руководителям» такой подход ближе, чем «с серьезным лицом рассказывать о серьезных серьезностях, пока все слушатели похрапывают на галерке».
Попутно продолжали текущие проекты (битриксы-шмитриксы, автоматизации, отчетности, дашборды и т.д.), решали задачи компаний, находящихся на сопровождении.
И вот в этом всем, как-то до блога руки не доходили. А постить «нейронный контент» не хотелось. Им и так сейчас все злоупотребляют.
Но есть очень важная вещь, которой хочется поделиться. Пока проводили тренинги, пришла идея провести открытый вебинар про то, как цифровая сознательность позволяет экономить деньги.
Один из наиболее частых вопросов он про «а где тут деньги и профиты». И правда, бизнес он же про деньги, а не про «оптимизацию ради оптимизации, и чтобы скучно не было». Да и сотрудники в общем тоже про деньги. «А оно мне зачем эта ваша цифровая сознательность. Сижу себе работаю, как учили. Не мешаю никому».
Но ровно в тот момент, когда бизнес начинает понимать, а где тут деньги, а сотрудник видит потенциал своего роста в деньгах, в этот момент отношение ко всему меняется.
Вот как раз об этом и поговорим 18.08.2023 в 10.00. 👉Жмакай, чтобы зарегистрироваться👈 Вебинар будет о серьезном.
🔥2
Рефлексия по результатам прошедшего вебинара.
Вебинар получился насыщенным, обсудили:
- из чего складывается ценообразование ИТ-проектов;
- как оптимизировать расходы на проект;
- как распределять компетенции между сотрудниками компании и ИТ-исполнителями;
- обсудили кейсы, как надо и как не надо реализовывать цифровые проекты;
- поговорили про фреймворк цифровой сознательности и как развивать цифровую сознательность.
Вебинар в записи можно посмотреть по той же ссылке, которая указана выше.
Ну или можно сходить в специального бота, которого сделали по этому поводу, оценить пользовательский путь, получить все мои актуальные контакты и вернуться в этот же канал. Маркетинг он такой маркетинг🤣🤣🤣
Примечательно другое, что пока обсуждали вопросы на вебинаре затронули тему, а как эту самую цифровую сознательность, которая так классно экономит ресурсы и двигает компании в сторону цифровых изменений, развить самостоятельно.
На вебинаре я озвучил варианты, среди которых в том числе, самое действенное:
- поучаствовать в цифровом проекте в качестве заказчика (или эксперта от заказчика)
и
- развивать насмотренность (трендвотчинг и промышленно-маркетинговый шпионаж).
И во время рефлексии по вебинару у меня возникли вопросы.
1) а как рядовому специалисту поучаствовать в цифровом проекте, когда никому в его компании из руководителей или топов это не надо
2) и где развивать насмотренность, когда по сути особо никто не рынке не хвастается своими достижениями в цифровизации.
Есть несколько коробочных решений (в которых, если честно, с моей точки зрения, с ходу не разберёшься) и есть офигительный маркетинг, надетый на попытку продать консультации экспертов, как в том сервисе по автоматизации бухгалтерии на основании ИИ, за которым реально сидели люди (ссылка в конце поста). Последнее относится к целому классу «ИТ решений и платформ», но не буду об этом.
Так вот задался я этими вопросами, и понял, что ответ простой «никак». Ну только что, пытаться читать паблики про технологии и пытаться сделать то, что я называю «цифровое мышление» - понять, как эту технологию применить на своём участке работы.
Поэтому я подумал, что будет полезно регулярно показывать какие-то кейсы, или делать микрообзоры продуктов, решений и технологий с их прикладным использованием в отрасли на примерах. Я чуть выше в видео по нейронкам начал это, вот хочу продолжать.
Но при этом, мне подумалось, что имеет смысл предлагать подписчикам самим выбирать, что для вас более актуально.
Поэтому следующий постом проведу голосование по вопросам, которые, как мне кажется, может быть полезно осветить, а голосование покажет, что из этого вызывает наибольший интерес.
https://www.forbes.ru/tehnologii/405589-kak-razrushilsya-startap-godami-vydavavshiy-armiyu-buhgalterov-za-iskusstvennyy
Вебинар получился насыщенным, обсудили:
- из чего складывается ценообразование ИТ-проектов;
- как оптимизировать расходы на проект;
- как распределять компетенции между сотрудниками компании и ИТ-исполнителями;
- обсудили кейсы, как надо и как не надо реализовывать цифровые проекты;
- поговорили про фреймворк цифровой сознательности и как развивать цифровую сознательность.
Вебинар в записи можно посмотреть по той же ссылке, которая указана выше.
Ну или можно сходить в специального бота, которого сделали по этому поводу, оценить пользовательский путь, получить все мои актуальные контакты и вернуться в этот же канал. Маркетинг он такой маркетинг🤣🤣🤣
Примечательно другое, что пока обсуждали вопросы на вебинаре затронули тему, а как эту самую цифровую сознательность, которая так классно экономит ресурсы и двигает компании в сторону цифровых изменений, развить самостоятельно.
На вебинаре я озвучил варианты, среди которых в том числе, самое действенное:
- поучаствовать в цифровом проекте в качестве заказчика (или эксперта от заказчика)
и
- развивать насмотренность (трендвотчинг и промышленно-маркетинговый шпионаж).
И во время рефлексии по вебинару у меня возникли вопросы.
1) а как рядовому специалисту поучаствовать в цифровом проекте, когда никому в его компании из руководителей или топов это не надо
2) и где развивать насмотренность, когда по сути особо никто не рынке не хвастается своими достижениями в цифровизации.
Есть несколько коробочных решений (в которых, если честно, с моей точки зрения, с ходу не разберёшься) и есть офигительный маркетинг, надетый на попытку продать консультации экспертов, как в том сервисе по автоматизации бухгалтерии на основании ИИ, за которым реально сидели люди (ссылка в конце поста). Последнее относится к целому классу «ИТ решений и платформ», но не буду об этом.
Так вот задался я этими вопросами, и понял, что ответ простой «никак». Ну только что, пытаться читать паблики про технологии и пытаться сделать то, что я называю «цифровое мышление» - понять, как эту технологию применить на своём участке работы.
Поэтому я подумал, что будет полезно регулярно показывать какие-то кейсы, или делать микрообзоры продуктов, решений и технологий с их прикладным использованием в отрасли на примерах. Я чуть выше в видео по нейронкам начал это, вот хочу продолжать.
Но при этом, мне подумалось, что имеет смысл предлагать подписчикам самим выбирать, что для вас более актуально.
Поэтому следующий постом проведу голосование по вопросам, которые, как мне кажется, может быть полезно осветить, а голосование покажет, что из этого вызывает наибольший интерес.
https://www.forbes.ru/tehnologii/405589-kak-razrushilsya-startap-godami-vydavavshiy-armiyu-buhgalterov-za-iskusstvennyy
🔥2👍1
О чем подготовить материал?
Anonymous Poll
19%
Как нейронками быстро анализировать документы (загрузил ТК - получил резюме или возможность диалога)
35%
Как нейронками быстро сделать презентацию или отчёт
68%
Про подбор кода ТНВЭД и ИИ
19%
В целом про автоматизацию декларирования о которой до этого много писАл
0%
Что-то иное (укажите к комментарии)
А еще - немного про санкции.
Конец прошлой недели для меня ознаменовался тем, то на краснейшей криптобирже Binance Россиянам запретили операции в валютах, отличных от рублей.
Как бы попытки разные были и раньше, но сейчас это уже ощутимо.
Понятно, что не бинансом единым живет крипта. На хуоби все работает и будет работать (я так думаю). Если поискать, то и ещё альтернативные биржи можно найти.
Но у меня сразу ассоциативный трендвотчинг сработал. Интересно, а будет что-то типа «турецких торговых домов», но только для крипты? Когда будет условная p2p прослойка «нерезидент», которая будет принимать платёж в рублях и возвращать usdt. До тех пор пока, есть альтернативные биржи это не актуально, но в целом, возможно такая «связка» в какой-то момент зачем-то появится.
А вообще, конечно, в такой момент понимаешь, как шатки все конструкции про «крипту, которая вне политики и ограничений и про свободу передвижения денежных средств». Интересно, как сейчас люди будут прорабатывать альтернативные каналы.
И тут, кажется, что имеет смысл смотреть за арбитражниками (это те товарищи, которые крутят «купи-продай на крипте» и за счёт разницы в курсах на разных биржах и/или крипто-обменниках набирают себе плюс в деньгах с оборота определённой суммы денег). Они-то явно свой бизнес терять не захотят и максимально быстро перестроятся на новые реалии.
https://www.ixbt.com/news/2023/08/26/binance-zapretila-rossijanam-provodit-p2poperacii-so-vsemi-valjutami-krome-rublja.amp.html
Конец прошлой недели для меня ознаменовался тем, то на краснейшей криптобирже Binance Россиянам запретили операции в валютах, отличных от рублей.
Как бы попытки разные были и раньше, но сейчас это уже ощутимо.
Понятно, что не бинансом единым живет крипта. На хуоби все работает и будет работать (я так думаю). Если поискать, то и ещё альтернативные биржи можно найти.
Но у меня сразу ассоциативный трендвотчинг сработал. Интересно, а будет что-то типа «турецких торговых домов», но только для крипты? Когда будет условная p2p прослойка «нерезидент», которая будет принимать платёж в рублях и возвращать usdt. До тех пор пока, есть альтернативные биржи это не актуально, но в целом, возможно такая «связка» в какой-то момент зачем-то появится.
А вообще, конечно, в такой момент понимаешь, как шатки все конструкции про «крипту, которая вне политики и ограничений и про свободу передвижения денежных средств». Интересно, как сейчас люди будут прорабатывать альтернативные каналы.
И тут, кажется, что имеет смысл смотреть за арбитражниками (это те товарищи, которые крутят «купи-продай на крипте» и за счёт разницы в курсах на разных биржах и/или крипто-обменниках набирают себе плюс в деньгах с оборота определённой суммы денег). Они-то явно свой бизнес терять не захотят и максимально быстро перестроятся на новые реалии.
https://www.ixbt.com/news/2023/08/26/binance-zapretila-rossijanam-provodit-p2poperacii-so-vsemi-valjutami-krome-rublja.amp.html
👍3
Материал про ИИ и классификацию записали, смонтируем и выложу, так что имеющим терпение воздастся.
А пока напишу про очень интересный диалог, который у меня состоялся на этой неделе.
Случилось у меня деловое общение с командой разработки, такой взрослой, уровня Enterprise (это про корпорации, с большими бюджетыми и всей ИТ-шной «серьезностью» из серии «нет формализованного бизнес-процесса – нет автоматизации»).
Чтобы было понятно, именно из-за этого подхода, очень многие компании не идут в автоматизацию. Им кажется, что все очень сложно и дорого, и иногда не понятно ради чего:
- сначала сформируй карту процессов
- нагенерируй регламентов, потом их внедри
- декомпозируй функции и т.д.
- и где-то там через несколько месяцев и потраченных бюджетов начало каких-то внедрений, которые можно потрогать руками.
И все это за деньги, с неочевидными для многих результатами (про регламенты в стол, я думаю все знают не по наслышке).
Поверьте, я не против такого подхода, и даже это очень правильный подход.
Но я также адекватно понимаю, что это не единственный возможный подход. Но «взрослые, серьезные ИТ команды», они именно про бизнес-культуру и если этого нет, то и проект, давайте назовем для них «неинтересный».
Так вот этой ИТ команде предложили рассмотреть возможность реализовать цифровой проект для… Теперь внимание… Компании в Казахстане, которая на волне последний актуальных тенденций прилично нарастила обороты и задумалась об автоматизации. То есть интересные бюджеты уровня Enterprise есть, но…
Ребята очень сильно сомневаются брать этот проект или не брать, именно по причине указанного выше.
Цифровой проект – это не только цифровое решение, но и цифровая культура, да и в общем в целом культура бизнеса. И как бы по факту, они скорее не хотят брать этот проект, именно по причине особенностей бизнес-подхода в ВЭД, и с оговоркой на региональные особенности.
И я вот что по этому поводу думаю.
Конечно правильно идти от бизнес-процесса к автоматизации. Это очень конкретный путь.
Но, в случае с ВЭД (особенно среднего размера компании, скажем так в пределах 50-100 человек), можно и от обратного.
Внедрение цифрового инструмента (допустим учетной системы), оно само может напрямую повлиять на проявление (не появления, а именно проявление) процесса. Потому что внесение данных в систему вовремя – это как раз приводит к определенной регламентности, и внедрение системы оно само по себе и является тем толчком, который вводит дисциплину работы с данными. Да, тут нужен контроль и помощь с внедрением, но это тоже работает.
И порой, это работает значительно быстрее и эффективнее, чем подход «отрегламентируй компанию по полной», а уже потом автоматизируй.
Только в этом случае совмещаются сразу 2 направления, экономится время, да и что уж, денежные ресурсы тоже.
Поэтому гибкость в подходе к цифровым проектам – это залог результата. При этом гибкость с двух сторон: и заказчика и разработчика. Можно по разному, главное, что было желание и готовность со стороны заказчика участвовать в проекте, а команды разработки идти навстречу и проявлять гибкость.
Ну цифровая сознательность, это как раз те компетенции, которые позволяют выстроить правильное взаимодействие и подобрать ту команду и цифровое решение, которое актуально для Вашей компании. А не пытаться «с болью натянуть уже существующий бизнес на коробочное решение». Либо наоборот, но тоже с болью.
А пока напишу про очень интересный диалог, который у меня состоялся на этой неделе.
Случилось у меня деловое общение с командой разработки, такой взрослой, уровня Enterprise (это про корпорации, с большими бюджетыми и всей ИТ-шной «серьезностью» из серии «нет формализованного бизнес-процесса – нет автоматизации»).
Чтобы было понятно, именно из-за этого подхода, очень многие компании не идут в автоматизацию. Им кажется, что все очень сложно и дорого, и иногда не понятно ради чего:
- сначала сформируй карту процессов
- нагенерируй регламентов, потом их внедри
- декомпозируй функции и т.д.
- и где-то там через несколько месяцев и потраченных бюджетов начало каких-то внедрений, которые можно потрогать руками.
И все это за деньги, с неочевидными для многих результатами (про регламенты в стол, я думаю все знают не по наслышке).
Поверьте, я не против такого подхода, и даже это очень правильный подход.
Но я также адекватно понимаю, что это не единственный возможный подход. Но «взрослые, серьезные ИТ команды», они именно про бизнес-культуру и если этого нет, то и проект, давайте назовем для них «неинтересный».
Так вот этой ИТ команде предложили рассмотреть возможность реализовать цифровой проект для… Теперь внимание… Компании в Казахстане, которая на волне последний актуальных тенденций прилично нарастила обороты и задумалась об автоматизации. То есть интересные бюджеты уровня Enterprise есть, но…
Ребята очень сильно сомневаются брать этот проект или не брать, именно по причине указанного выше.
Цифровой проект – это не только цифровое решение, но и цифровая культура, да и в общем в целом культура бизнеса. И как бы по факту, они скорее не хотят брать этот проект, именно по причине особенностей бизнес-подхода в ВЭД, и с оговоркой на региональные особенности.
И я вот что по этому поводу думаю.
Конечно правильно идти от бизнес-процесса к автоматизации. Это очень конкретный путь.
Но, в случае с ВЭД (особенно среднего размера компании, скажем так в пределах 50-100 человек), можно и от обратного.
Внедрение цифрового инструмента (допустим учетной системы), оно само может напрямую повлиять на проявление (не появления, а именно проявление) процесса. Потому что внесение данных в систему вовремя – это как раз приводит к определенной регламентности, и внедрение системы оно само по себе и является тем толчком, который вводит дисциплину работы с данными. Да, тут нужен контроль и помощь с внедрением, но это тоже работает.
И порой, это работает значительно быстрее и эффективнее, чем подход «отрегламентируй компанию по полной», а уже потом автоматизируй.
Только в этом случае совмещаются сразу 2 направления, экономится время, да и что уж, денежные ресурсы тоже.
Поэтому гибкость в подходе к цифровым проектам – это залог результата. При этом гибкость с двух сторон: и заказчика и разработчика. Можно по разному, главное, что было желание и готовность со стороны заказчика участвовать в проекте, а команды разработки идти навстречу и проявлять гибкость.
Ну цифровая сознательность, это как раз те компетенции, которые позволяют выстроить правильное взаимодействие и подобрать ту команду и цифровое решение, которое актуально для Вашей компании. А не пытаться «с болью натянуть уже существующий бизнес на коробочное решение». Либо наоборот, но тоже с болью.
👍4
Доброго дня!
Час назад получил задачу сделать MVP учетной системы для процессов экспедирования за…
Рам пам пам неделю и один день.
То есть в среду 27.12.2023 я должен заказчику показать функционирующую систему (хотя бы по минималке) под следующие требования:
1) загрузка данных в систему по форме извне (стандартизованный Эксель файл, с которым сейчас работают)
2) обеспечить процесс контроля статусов поставки
3) обеспечить инструмент оперативного контроля «тревожных статусов» (опаздывает и т.д.).
Я взялся за эту задачу. И чтобы как-то ещё больше себя замотивировать, решил сделать из этого что-то вроде реалити-шоу, где делюсь тем, как все будет происходить, со всеми удачами и факапами (надеюсь все же с удачами).
Видео-контент буду тоже выкладывать. Но в режиме +- реального времени он будет в соц. сети, которая в РФ признана запрещённой (там меня можно найти @in.makarchuk).
Сюда буду выкладывать, но спокойнее, так как тут скорее про «писАть, чем про смотреть».
Для меня это правда вызов. Полагаю и для вас будет занимательно, а что реально можно сделать за неделю.
Как-то так.
Час назад получил задачу сделать MVP учетной системы для процессов экспедирования за…
Рам пам пам неделю и один день.
То есть в среду 27.12.2023 я должен заказчику показать функционирующую систему (хотя бы по минималке) под следующие требования:
1) загрузка данных в систему по форме извне (стандартизованный Эксель файл, с которым сейчас работают)
2) обеспечить процесс контроля статусов поставки
3) обеспечить инструмент оперативного контроля «тревожных статусов» (опаздывает и т.д.).
Я взялся за эту задачу. И чтобы как-то ещё больше себя замотивировать, решил сделать из этого что-то вроде реалити-шоу, где делюсь тем, как все будет происходить, со всеми удачами и факапами (надеюсь все же с удачами).
Видео-контент буду тоже выкладывать. Но в режиме +- реального времени он будет в соц. сети, которая в РФ признана запрещённой (там меня можно найти @in.makarchuk).
Сюда буду выкладывать, но спокойнее, так как тут скорее про «писАть, чем про смотреть».
Для меня это правда вызов. Полагаю и для вас будет занимательно, а что реально можно сделать за неделю.
Как-то так.
🔥3
Media is too big
VIEW IN TELEGRAM
Тоже самое, но голосом и на «взаправдашних эмоциях», ведь в роли говорящей головы я ещё не научился быть, как это положено стандартами блогеров🤣🤣🤣
🔥3💯1🫡1
Итак, день 1 (20.12.2023).
По сути сегодня был день подготовительный: закрыть все плановое, включить вот этот внеплановый вызов в работу себя и команды, оценить реальность проекта.
Мысли, почему задача, кажется, реальной:
1. Процесс, который надо на старте представить, условно типовой для отрасли (заявка, тендеровка у подрядчиков, фиксация ставки, формирование документов, контроль перевозки, финансовые документы, финансовые показатели).
2. В качестве системы реализации мной предложен, а заказчиком согласован Битрикс24
3. У меня есть отработанная конфигурация битрикса под процессы экспедирования и ТО (я ее назвал Logistix24), которая имеет несколько успешных внедрений. То есть мы четко понимаем, как конкретная ВЭД задача может быть решена на механиках и инструментах Битрикс24.
4. Битрикс24 + отраслевая конфигурация (это даже не корбочное решение, а именно набор логик и алгоритмов) дает удивительное сочетание, которое я называю «коробка трансформер», то есть оно позволяет решить базовые функциональные потребности, но при этом достаточно гибко адаптируется под специфику конкретной компании (последовательность этапов, выполняемые функциональные роли, перечень автоматизаций и интеграций).
5. Мне и команде не надо сильно объяснять, что должно получиться, так как все это уже делалось неоднократно, и мы из отрасли и про отрасль. Отсюда возможность сэкономить время на технической документации в классическом ее проявлении.
6. Заказчик, в целом, понимает свой процесс, и имеет опыт работы с цифровыми инструментами. Нарисованный, как я называю, на салфетке схематический процесс, подкрепленный сессией вопрос-ответ, в целом позволяет сформировать технические требования к результату.
6. Заказчик адекватно (как кажется) понимает, что через неделю это что-то среднее между MVP и прототипом. Уже не прототип, потому что в нем реально можно работать, но и не полноценная 100% отстроенная система. То есть тут именно MVP с которым реально можно работать или его тестировать, но с пониманием, что марафет и монстр-фичи надо будет проработать и реализовать отдельно.
Нюансы и риски:
1. Основной риск – это моя самонадеянность, что я без классического «согласуй технические требования и потом техническое задание» берусь что-то делать. По сути я проявляю за заказчика особую активность, где-то додумываю и как бы говорю, что вот тебе надо именно вот так, как я сделал. Но эта достаточно рискованная практика, и были достаточно неприятные опыты.
2. В нашей настройке Logistix24 мы не делали модульным блоком «тендеровку» (названо громко, но суть именно такая), так как по практике процесс «согласуй заявку с подрядчиком», часто заказчики оставляют в формате «на откуп исполнителю». Я не считаю, что это правильно. Но рынок есть рынок. И мы в рамках делай то, что тебя просят, фокус внимания уделяли наиболее часто запрашиваемому функционалу. А в этом проекте, этот модуль является одним из ключевых. И его надо как-то (хотя бы приблизительно) реализовать на уровне логики и инструмента.
3. Уже в группе с заказчиком началась активное обсуждение функционала, и есть высокая вероятность, что та идея продукта, которая была озвучена при первом общении, может радикально измениться вот в этом обсуждении. Это по сути продолжения п.1 из рисков.
4. Сроки, так как неделя – это прям очень не много, даже с условием опыта меня и команды.
Но как бы там ни было, взялся за гуж не говори что не дюж.
План выглядит так.
Четверг: составить структуру данных, логику статусов и перечень автоматизаций – отправить на согласование заказчику.
Пятница: получить обратную связь и корректировки.
Далее: перенести в режиме турбо-экспресс все это на Битрикс24.
Среда: презентовать заказчику и провести инструктаж по работе для тестирования.
А вот получится выдержать темп или не получится – время покажет.
ПС: понятное дело, что вот этот анализ проводится до обозначения сроков проекта. И по классике надо было сначала собрать все тех.требования и сделать драфт технического задания, а потом уже говорить про сроки. В общем, обычно так никто не делает.
По сути сегодня был день подготовительный: закрыть все плановое, включить вот этот внеплановый вызов в работу себя и команды, оценить реальность проекта.
Мысли, почему задача, кажется, реальной:
1. Процесс, который надо на старте представить, условно типовой для отрасли (заявка, тендеровка у подрядчиков, фиксация ставки, формирование документов, контроль перевозки, финансовые документы, финансовые показатели).
2. В качестве системы реализации мной предложен, а заказчиком согласован Битрикс24
3. У меня есть отработанная конфигурация битрикса под процессы экспедирования и ТО (я ее назвал Logistix24), которая имеет несколько успешных внедрений. То есть мы четко понимаем, как конкретная ВЭД задача может быть решена на механиках и инструментах Битрикс24.
4. Битрикс24 + отраслевая конфигурация (это даже не корбочное решение, а именно набор логик и алгоритмов) дает удивительное сочетание, которое я называю «коробка трансформер», то есть оно позволяет решить базовые функциональные потребности, но при этом достаточно гибко адаптируется под специфику конкретной компании (последовательность этапов, выполняемые функциональные роли, перечень автоматизаций и интеграций).
5. Мне и команде не надо сильно объяснять, что должно получиться, так как все это уже делалось неоднократно, и мы из отрасли и про отрасль. Отсюда возможность сэкономить время на технической документации в классическом ее проявлении.
6. Заказчик, в целом, понимает свой процесс, и имеет опыт работы с цифровыми инструментами. Нарисованный, как я называю, на салфетке схематический процесс, подкрепленный сессией вопрос-ответ, в целом позволяет сформировать технические требования к результату.
6. Заказчик адекватно (как кажется) понимает, что через неделю это что-то среднее между MVP и прототипом. Уже не прототип, потому что в нем реально можно работать, но и не полноценная 100% отстроенная система. То есть тут именно MVP с которым реально можно работать или его тестировать, но с пониманием, что марафет и монстр-фичи надо будет проработать и реализовать отдельно.
Нюансы и риски:
1. Основной риск – это моя самонадеянность, что я без классического «согласуй технические требования и потом техническое задание» берусь что-то делать. По сути я проявляю за заказчика особую активность, где-то додумываю и как бы говорю, что вот тебе надо именно вот так, как я сделал. Но эта достаточно рискованная практика, и были достаточно неприятные опыты.
2. В нашей настройке Logistix24 мы не делали модульным блоком «тендеровку» (названо громко, но суть именно такая), так как по практике процесс «согласуй заявку с подрядчиком», часто заказчики оставляют в формате «на откуп исполнителю». Я не считаю, что это правильно. Но рынок есть рынок. И мы в рамках делай то, что тебя просят, фокус внимания уделяли наиболее часто запрашиваемому функционалу. А в этом проекте, этот модуль является одним из ключевых. И его надо как-то (хотя бы приблизительно) реализовать на уровне логики и инструмента.
3. Уже в группе с заказчиком началась активное обсуждение функционала, и есть высокая вероятность, что та идея продукта, которая была озвучена при первом общении, может радикально измениться вот в этом обсуждении. Это по сути продолжения п.1 из рисков.
4. Сроки, так как неделя – это прям очень не много, даже с условием опыта меня и команды.
Но как бы там ни было, взялся за гуж не говори что не дюж.
План выглядит так.
Четверг: составить структуру данных, логику статусов и перечень автоматизаций – отправить на согласование заказчику.
Пятница: получить обратную связь и корректировки.
Далее: перенести в режиме турбо-экспресс все это на Битрикс24.
Среда: презентовать заказчику и провести инструктаж по работе для тестирования.
А вот получится выдержать темп или не получится – время покажет.
ПС: понятное дело, что вот этот анализ проводится до обозначения сроков проекта. И по классике надо было сначала собрать все тех.требования и сделать драфт технического задания, а потом уже говорить про сроки. В общем, обычно так никто не делает.
👍3
image_2023-12-21_18-37-32.png
353.7 KB
ТЗ подготовили, отправили заказчику. Проблемные вопросы выделили для обсуждения.
Сегодня позже (завтра все-таки) поделюсь итогами дня и рефлексией и проблематикой.
image_2023-12-21_18-38-29.png
38.5 KB
И да, ТЗ действительно существует🤣🤣🤣🤣 Также как заказчик и проект
👎1🤔1
День 2 (21.12.23) Рефлексия и нюансы.
Задача была подготовить ТЗ и отправить заказчику на согласование.
На этот момент имели:
1) образцы таблиц, которые у себя ведёт заказчик (Эксель)
2) общую схему процесса «на салфетке»
3) общение с описанием что есть и чего хочется.
Задача, как ее поставил я у себя в команде:
1) на основе имеющихся у заказчика таблиц собрать состав данных для информационной карточки сущности, вокруг которой будет строиться процесс в Б24
2) указать тип данных (текст, даты, выпадающий список и т.д.)
3) на базе имеющейся информации от заказчика разработать систему статусов, которые должна иметь информационная сущность (поставка на согласовании, ожидается, в пути, отгружена, выставить счёт и т.д.)
4) определить перечень автоматизаций, которые нужны в целом и на первом этапе
5) предложить варианты оперативных отчётов, которые предполагается формировать для оперативного управления.
Задача в целом типовая для подобного проекта. С учётом того, что все экспедиторы +- работают одинаково, Таблицы выедут +- схожие и процесс в целом тоже схожий, то тут проблем не было.
Плюсом является то, что отрасль знакомая и нам не надо лишний раз уточнять, что значит поле «отметка СКК» или «СВХ/терм. приб.».
ТЗ вчера отправили. Так что пока идём по плану.
Задача была подготовить ТЗ и отправить заказчику на согласование.
На этот момент имели:
1) образцы таблиц, которые у себя ведёт заказчик (Эксель)
2) общую схему процесса «на салфетке»
3) общение с описанием что есть и чего хочется.
Задача, как ее поставил я у себя в команде:
1) на основе имеющихся у заказчика таблиц собрать состав данных для информационной карточки сущности, вокруг которой будет строиться процесс в Б24
2) указать тип данных (текст, даты, выпадающий список и т.д.)
3) на базе имеющейся информации от заказчика разработать систему статусов, которые должна иметь информационная сущность (поставка на согласовании, ожидается, в пути, отгружена, выставить счёт и т.д.)
4) определить перечень автоматизаций, которые нужны в целом и на первом этапе
5) предложить варианты оперативных отчётов, которые предполагается формировать для оперативного управления.
Задача в целом типовая для подобного проекта. С учётом того, что все экспедиторы +- работают одинаково, Таблицы выедут +- схожие и процесс в целом тоже схожий, то тут проблем не было.
Плюсом является то, что отрасль знакомая и нам не надо лишний раз уточнять, что значит поле «отметка СКК» или «СВХ/терм. приб.».
ТЗ вчера отправили. Так что пока идём по плану.
👍1
Про нюансы
Нюансы, как обычно, вылезли на этапе формирования выпадающих списков. Когда это ведётся в ручную то условный «отправитель А» имеет несколько вариаций написания:
- отправитель А
- отправитель_А
- отпр. А (а латинская) и т.д.
А чистота данных такого не терпит.
Обычно «причесать» такого рода списки - это задача Заказчика. Но в рамках очень сжатых сроков я эту задачу взял на команду. Там не так сложно, чтобы это нельзя было сделать самим. Но естественно при такой «чистке» данных нельзя без согласования рубить с плеча, потому что мы можем не знать нюансы отображения данных заказчиком.
То есть аналитик сгруппировал схожие данные (которые похожи на дубли) и дальше наша задача !!!совместно с заказчиком!!! свести в все к единому списку.
Второй нюанс для согласования - это необходимость тех или иных полей уже исходя из практики.
То есть прям из этого кейса: есть поле «контроль СКК», и оно через раз заполняется да/нет, где-то не заполняется, а где-то в нем просто текстовый комментарий, не относящий к санитарно-карантинному контролю. Что с этим делать - это решает заказчик. Но сразу становится очевидно, то мы добавляем поле «комментарий» в структуру данных, которого в исходных данных от заказчика не было, и этим полем становится любое поле, в зависимости от менеджера, который заполнял таблицу.
Ну и вопрос достаточности, о котором я говорил раньше в видео.
Достаточности обобщения частностей и отклонений. И достаточности детализации информации в технической документации. Тут, кончено, со мной многие ИТ интеграторы и/или IT-службы могут вступить в спор, что чем дательнее, тем более гарантированный результат итого. И я даже не буду с ними, спорить. В этом есть правда.
Но и есть другая правда, у любой задачи есть уровень достаточности «усложнения подхода». Уметь находить компромисс достаточности - это по сути компромисс ресурсов «время - деньги - результат».
То есть уйти в глубину отклонений от типового процесса или в детализацию описания - всегда можно. Но у нас задача двигаться в срок к конкретной цели. И эта цель ко вторнику следующей недели - показать типовой процесс. Значит типовой процесс и моделируем (закопаться в отклонения - всегда успеем, но и отклонения они на то отклонения, что их статистически значительно меньше случаев, чем типовых).
Через 15 минут, кстати, созвон с заказчиком по ТЗ. Но это уже в отчёт сегодняшнего дня.
Нюансы, как обычно, вылезли на этапе формирования выпадающих списков. Когда это ведётся в ручную то условный «отправитель А» имеет несколько вариаций написания:
- отправитель А
- отправитель_А
- отпр. А (а латинская) и т.д.
А чистота данных такого не терпит.
Обычно «причесать» такого рода списки - это задача Заказчика. Но в рамках очень сжатых сроков я эту задачу взял на команду. Там не так сложно, чтобы это нельзя было сделать самим. Но естественно при такой «чистке» данных нельзя без согласования рубить с плеча, потому что мы можем не знать нюансы отображения данных заказчиком.
То есть аналитик сгруппировал схожие данные (которые похожи на дубли) и дальше наша задача !!!совместно с заказчиком!!! свести в все к единому списку.
Второй нюанс для согласования - это необходимость тех или иных полей уже исходя из практики.
То есть прям из этого кейса: есть поле «контроль СКК», и оно через раз заполняется да/нет, где-то не заполняется, а где-то в нем просто текстовый комментарий, не относящий к санитарно-карантинному контролю. Что с этим делать - это решает заказчик. Но сразу становится очевидно, то мы добавляем поле «комментарий» в структуру данных, которого в исходных данных от заказчика не было, и этим полем становится любое поле, в зависимости от менеджера, который заполнял таблицу.
Ну и вопрос достаточности, о котором я говорил раньше в видео.
Достаточности обобщения частностей и отклонений. И достаточности детализации информации в технической документации. Тут, кончено, со мной многие ИТ интеграторы и/или IT-службы могут вступить в спор, что чем дательнее, тем более гарантированный результат итого. И я даже не буду с ними, спорить. В этом есть правда.
Но и есть другая правда, у любой задачи есть уровень достаточности «усложнения подхода». Уметь находить компромисс достаточности - это по сути компромисс ресурсов «время - деньги - результат».
То есть уйти в глубину отклонений от типового процесса или в детализацию описания - всегда можно. Но у нас задача двигаться в срок к конкретной цели. И эта цель ко вторнику следующей недели - показать типовой процесс. Значит типовой процесс и моделируем (закопаться в отклонения - всегда успеем, но и отклонения они на то отклонения, что их статистически значительно меньше случаев, чем типовых).
Через 15 минут, кстати, созвон с заказчиком по ТЗ. Но это уже в отчёт сегодняшнего дня.
👍1