Материал про ИИ и классификацию записали, смонтируем и выложу, так что имеющим терпение воздастся.
А пока напишу про очень интересный диалог, который у меня состоялся на этой неделе.
Случилось у меня деловое общение с командой разработки, такой взрослой, уровня 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
This media is not supported in your browser
VIEW IN TELEGRAM
Вот так можно решить задачу поиска дублей с различной семантикой, но схожим смыслом с помощью нейронных сетей. И таких задач в обыденных процессах полно. Времени экономится прилично.
🔥5
День 3 – 4 (22 – 24.12.2023)
В общем тема блогерства и онлайн следов в эфире я не выдержал. Не круто конечно, но в принципе ожидаемо.
Еще более менее в «соц сети про жизнь» пару сториз успел запостить в моменте, тут, увы нет.
Но, главное, что сам проект двигается почти по плану.
22.12.2023 был запланирован созвон и он состоялся. Было долгова-то для созвона. На 2,5 часа стараюсь подобные встречи не растягивать, но тут уже надо было все в одно успеть.
Все обсудили.
Из положительного, в целом основные вопросы сняли.
Из обычного, в ходе общения вылезло конечно же куча нюансов, основной из которых логическое продолжение «грязи в классификаторах».
Суть в том, что на первом этапе внедрения данные в битрикс24 будут попадать извне (и точнее из экселей). Не будем сейчас о том, «почему именно так, и что это все структурно не правильно». Да, неправильно, да не круто, да лишние проблемы, которых можно было бы избежать.
И как всегда в логистики, так надо.
Раз надо, значит надо. Опять же я не могу все детали раскрывать «почему так, а не иначе», а там есть аргументы.
Вернемся к проблеме:
во входящих данных бардак, в битриксе надо этот бардак исправлять на классификаторы.
Возникает вопрос на каком из этапов и в какой среде:
- при сборе данных
- при подготовке данных на загрузку
- уже внутри битрикса?
И тут тоже много нюансов из серии, чем осуществляем чистку данных (VBA, PHP, Python), «битрикс коробока» и «битрикс облако», все это разные возможности на программирование.
Итого вопросов поприбавилось.
Положительный момент, что встреча состоялась. И со стороны заказчика организационный контроль выдержан. Потому что у меня очень много опытов, когда в силу текущей «перегруженности» участников проекта со стороны заказчика встречи переносятся постоянно.
Итог:
- обсудили, пул проблемных вопросов с учетом глубокого погружения в материалы;
- сформулировали часть необходимых логических решений;
- ожидание от демонстрации во вторник синхронизировали.
23-24.12 выходные.
🔥🔥🔥🔥
Тут должен выразить огромную благодарность моим партнерам по команде. Несмотря на выходные коллеги нашли несколько часов, чтобы сделать то, что необходимо было, чтобы двигаться дальше.
Вошли в ситуацию и поддержали темп.
В общем тема блогерства и онлайн следов в эфире я не выдержал. Не круто конечно, но в принципе ожидаемо.
Еще более менее в «соц сети про жизнь» пару сториз успел запостить в моменте, тут, увы нет.
Но, главное, что сам проект двигается почти по плану.
22.12.2023 был запланирован созвон и он состоялся. Было долгова-то для созвона. На 2,5 часа стараюсь подобные встречи не растягивать, но тут уже надо было все в одно успеть.
Все обсудили.
Из положительного, в целом основные вопросы сняли.
Из обычного, в ходе общения вылезло конечно же куча нюансов, основной из которых логическое продолжение «грязи в классификаторах».
Суть в том, что на первом этапе внедрения данные в битрикс24 будут попадать извне (и точнее из экселей). Не будем сейчас о том, «почему именно так, и что это все структурно не правильно». Да, неправильно, да не круто, да лишние проблемы, которых можно было бы избежать.
И как всегда в логистики, так надо.
Раз надо, значит надо. Опять же я не могу все детали раскрывать «почему так, а не иначе», а там есть аргументы.
Вернемся к проблеме:
во входящих данных бардак, в битриксе надо этот бардак исправлять на классификаторы.
Возникает вопрос на каком из этапов и в какой среде:
- при сборе данных
- при подготовке данных на загрузку
- уже внутри битрикса?
И тут тоже много нюансов из серии, чем осуществляем чистку данных (VBA, PHP, Python), «битрикс коробока» и «битрикс облако», все это разные возможности на программирование.
Итого вопросов поприбавилось.
Положительный момент, что встреча состоялась. И со стороны заказчика организационный контроль выдержан. Потому что у меня очень много опытов, когда в силу текущей «перегруженности» участников проекта со стороны заказчика встречи переносятся постоянно.
Итог:
- обсудили, пул проблемных вопросов с учетом глубокого погружения в материалы;
- сформулировали часть необходимых логических решений;
- ожидание от демонстрации во вторник синхронизировали.
23-24.12 выходные.
🔥🔥🔥🔥
Тут должен выразить огромную благодарность моим партнерам по команде. Несмотря на выходные коллеги нашли несколько часов, чтобы сделать то, что необходимо было, чтобы двигаться дальше.
Вошли в ситуацию и поддержали темп.
👍1