Добрый день.

Максимально простой пост 🙂

✨🎇✨✨🎆🎇✨🎆✨✨🎇

Мы выпустили линейку курсов "1С:Аналитик"

🎇🎆✨✨🎇✨🎆✨🎇✨🎆


1️⃣ Видеокурс «Введение в профессию 1С:Аналитик» – будет полезен тем, кто делает первые шаги в профессии «Аналитик». Курс поможет сформировать представление о профессии и ключевых навыках, попробовать себя в роли аналитика и наметить траекторию своего профессионального развития.
Ссылка для записи на курс

2️⃣ Видеокурс «1С:Аналитик. Развитие профессиональных компетенций» – предназначен для широкой аудитории, он будет полезен как начинающим аналитикам, так и тем, у кого есть опыт работы в этой роли. Курс позволит расширить и систематизировать знания, необходимые для выполнения задач аналитика в проектах.
Ссылка для записи на курс

3️⃣ Онлайн-курс «1С:Аналитик. Практикум» – ориентирован на специалистов, имеющих опыт выполнения проектов, а также слушателей курса «1С:Аналитик. Развитие профессиональных компетенций». Данный курс состоит только из практических занятий. Участники практикума решат сквозной кейс, выполнят домашние работы и получат развивающую обратную связь от преподавателей.
Ссылка для записи на курс

Подробности в инфописьме 34056 от 30.01.26

🎆🎇✨✨🎇🎆🎇✨

Коллеги, добрый день.

Тут в поле моего зрения попал сервис, для мня новый - 1С:Кабинет сотрудника.

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

❓ Почему?

‼️ Ну самое важное, в этом продукте чаще всего заинтересован средний и крупный бизнеса.
✅ И потом, клиенты, конечно в этом случае хотя работы "под ключ".

В итоге ... для того, чтобы обеспечить работу данного сервиса нужен прямо-таки проект:
1️⃣ Методическая работа, довольно массивный блок, без которого никак: аудит кадровых документов, процессов, шаблоны документов
2️⃣ Техническая работа по подготовке инфраструктуры
3️⃣ Консультационная работа: обучение пользователей, обеспечение поддержки
4️⃣ И, собственно, внедрение - подключение пользователей, настройки, интеграции.

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

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

❓ Скажите, а вы уже внедряли продукт 1С:КС?
❓ Верно ли мое предположение о полноценном проекте?
✏️ Поделитесь вашим мнением

💬

#Предметные_вопросы

Коллеги, здравствуйте.

Как ваши дела ❓
Как ваше строение в эти ❄️ зимние 🌨 морозные вечера ❄️ (или у вас тепло 🔥 ) ❓
Не замерзли ❓

А я предлагаю ПОИГРАТЬ ... Игры согревают ☀️

25.02.2026. Бизнес-игра "ПРЕСЕЙЛ". Но на какую тему ... ?

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

А как Вы убеждаете заказчика выбрать вашу архитектуру ❓
Или может оставляете выбор на потом ⏳
Какие аргументы подобрать в дебатах о лучшем варианте для проекта 💬
Что звучит убедительно 🤩, а какие доводы лучше не озвучивать 😐

Ссылка для записи

#Обучение_РП

Коллеги, добрый день.

Продолжая тему кейсов и ситуаций...

Возможно кейс вам покажется обычным, избитым, НО таким частым... Поэтому все же поделюсь...

Клиент из гостиничного бизнеса. Бюджетирование.
Стоит 1С:БП оооочень допиленная, свои системы по всяким околостоящим бизнесам - питание, торговые ряды, прачечная и т.д.

Договор примерно с такими формулировками:

Этап 1. Подготовка технического проекта и ограничений внедрения на основании модели Заказчика и текущих бизнес-процессов Заказчика
Этап 2. Настройка блока "Планирование"
- Разработка плана счетов и шаблона проводок
- Реализация НСИ
- Настройка шаблонов документов планирования
- Настройка зависимостей статей бюджета
Этап 3. Настройка отражения фактических данных по бюджету

В общем-то все как всегда...

Начинается проект.
Делается техническое решение, описываются ограничения, все кроме одного ☹️ ... И вот тут как раз то слово "ДРИЛДАУН".

Начинается реализация.
Сделали настройку "плана".
Приступаем к настройке "факта". Просят дрилдаун. (простите за простое слово) "Докуда????" - спрашиваем.
"А до исходника."
"Исходника в 1С:БП?" (мы же туда берем данные из всех систем - агрегированные).
"Нет. Хотим проваливаться прямо в исходные системы. Вот чтобы прям до чеков было видно".

Конечно все можно сделать, вопрос сроков и денег. Того, чего у нас не было в этом проекте 🥹

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

Коллеги, будьте внимательны:
1️⃣ при сборе требований, не проектном, а еще при сборе требований в момент формирования коммерческого предложения
2️⃣ при формировании и СОГЛАСОВАНИИ проектных решений и фиксации ограничений

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

Да, наверно, кейс избитый. Но тема блока "Бюджетирования" она вообще очень колуарная и очень обширная.

🎁 А какие "сюрпризы" еще бывают при внедрении "Бюджетирования"?
✍️ Поделитесь.

#Рассуждения_о_проектах

Коллеги, добрый день.

Возникла тема "Какие показатели можно использовать для оценки работы РП".

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

Итак...
Оценку РП я обычно провожу по 3 направлениям:

1️⃣ Период работы в компании. Несомненно важный показатель, почти надежность РП

2️⃣ Проекты. Анализ текущих и завершенных проектов. Тут целый ряд показателей:
• Количество клиентов, количество проектов. Ведь работать в одном клиенте на портфеле проектов не то же самое, как работать у разных клиентов в разных проектах
• Max/среднее количество человек в подчинении. Оцениваем какой командой управляет РП
• Max/Min/средний бюджет проекта. Оценка объема проекта
• Max/Min/средние трудозатраты по проектам проекта. Тоже оценка объема проекта
• Опыт работы с субподрядом. Важное умение, важный опыт
• Выручка – общая, средняя за месяц. Смотрим сколько вообще "прокачал" РП. И как прокачал, равномерно или усиленно поработал первые несколько месяцев
• Затраты – общие, средние за месяц. Аналогично, только с позиции затрат
• Сумма дебиторской задолженности. Тут, думаю, без уточнений
• Доли затрат на РП, архитектора, исполнителей. Показывает структуру проектной команды - сколько работает сам, привлекает ли архитектора, какова команда
• Доля затрат на РП приходящаяся на 1 час специалиста. Важный показатель, показывает, скажем так, накладные расходы РП на каждого предметного спеца. Особенно важно, если при оценке проектов, затраты на РП закладываются не часами, а статьей затрат
• В случае премиальной схемы, доли выплат в виде оклада, бонусов, доп. Выплат (отпуск, проезд, и т.п.). Собственно, какая структура дохода РП, насколько мотивирован и стремиться к премиям, или работает просто на окладе.

3️⃣ Продажи. Как работает РП в процедурах продаже, и вообще работает ли на продажу. Ведь должен же... Тут тоже несколько показателей:
• Количество проведенных пресейлов. Оценка привлечения РП продавцами на встречи и собственно сама активность РП
• Количество проведенных переговоров по вторичным продажам. Аналогично
• Количество успешных пресейлов/вторичных продаж. Показывает насколько эффективные продажи с участием этого РП. Конечно, продажа зависит не только от РП, но в совокупе и от него тоже
• Бюджет успешных пресейлов/вторичных продаж. Аналогично.

Коллеги, дополняйте ✍️, уточняйте 💭

#Предметные_вопросы

Коллеги, добрый день.

Ранее в канале вы спрашивали про

«Обновление ГОСТ Р 7.0.97-2025»

Тема важная и мы постарались для Вас подготовить краткую и емкую информацию ⬇️

‼️ Самое важное. На этот вопрос можно посмотреть с 2 сторон:
🫲 Применение, точнее соблюдение ГОСТ в проектах внедрения системы Документооборота
🫱 Применение ГОСТ для оформления именно проектной документации в рамках проектов внедрения различных систем. Т.е. как мы должны оформлять протоколы, Уставы, предметные документы и т.д., чтобы соответствовать ГОСТ

"Применение, точнее соблюдение ГОСТ в проектах внедрения системы Документооборота".

1️⃣ Согласитесь, что в рамках проектной деятельности мы сталкиваемся с различными нормативными документами и ГОСТами, и знать все документы практически невозможно.

На примере проекта по внедрению систем электронного документооборота, по состоянию на август 2025 года выявили порядка 190 нормативно-правовых документов и стандартов, в той или иной степени влияющих на процессы документооборота и внедрения информационной системы документооборота (СЭД). Конечно, не все нормативные документы используются в рамках одного проекта одновременно.
Поэтому важно разобраться: какие из них влияют на проект, а какие нет.

Об этом мы рассказывали на Дне документооборота 2025.
На сайте фирмы 1С можно ознакомиться с презентацией доклада «Основные нормативные документы по управлению документами и архивному делу».

2️⃣ Как показывает практика, среди многообразия нормативных документов можно выделить один ГОСТ, который точно всегда нужно учитывать в проектах по внедрению СЭД, а именно ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов».

В 2025 году были внесены изменения в этот ГОСТ, издана новая редакция.

Если вы хотите узнать об этих изменениях, но не тратить при этом свое время на сравнение старой и новой версии, вам будет полезно ознакомиться со статьей о ключевых изменениях «Новый ГОСТ Р 7.0.97-2025: изменения в оформлении документов».

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

"Применение ГОСТ для оформления именно проектной документации в рамках проектов внедрения различных систем".

Важно понимать, что ГОСТы носят рекомендательный характер, и заказчик проекта, может настаивать применять шаблоны документов, разработанных по требованиям заказчика.
Это частое требование крупных корпораций: свой проектный офис, брендбук корпоративный, который распространяется не только на документы, но и на цвета, используемые в интерфейсах информационных систем.
И если в вашем случае, заказчик выставляет требование работать по своим шаблонам документов - работаем по правилам заказчика.

Долматова Елена
Фирма "1С"

#Предметные_вопросы

Как используют ТКВ?

Добрый день.
Этакий провокационный пост. Провокационный не для вас, скорее для меня 😮😌

Опять про технологии внедрения. Про 1С:ТКВ. Такую большую, сложную, непонятную 🤕

Говорят, что 1С:ТКВ не применима… 😮😮😮

Давайте пообсуждаем этот вопрос… этот важный вопрос… ведь технологии создаются для того, чтобы их применяли…

В последнее время сталкиваюсь в 3 видами реакции на 1С:ТКВ. И звучат они примерно так:
1️⃣ 1С:ТКВ не применима в проектах, зачастую даже в корпоративных (причины называются разные и это тоже очень важно, можно отдельно обговорить этот вопрос)
2️⃣ 1С:ТКВ применима с адаптациями. То есть компании берут 1С:ТКВ читают ее, изучают, анализируют. И, или дополняют свою уже состоявшуюся технологию, или путем упрощения создают технологию по которой будут работать в компании. На мой взгляд, самый оптимальный вариант применения такого большого свода знаний, как ТКВ.
3️⃣ 1С:ТКВ иногда является даже базой для новых идей и инструментов. Об этом и на партнерском бывает говорят🙂

А вот вы знакомы с ТКВ?
Анализировали ли ее? ведь познакомиться мало, надо понять и прикинуть на себя.
Применяете в том или ином виде?

✏️ Поделитесь, пожалуйста, вашим мнением.

#Технологии_1С

Коллеги, здравствуйте.

Хочу поделиться с вами интересным документом, который попал ко мне в работу. Это проект "Принципов внедрения 1С", сформулированных командой заказчика. Это не техническое задание и не смета, а именно попытка сформировать "правила игры".

Предлагаю устроить открытый и, главное, честный разбор. ⚖️
Давайте попробуем абстрагироваться от привычной роли "исполнителя, который хочет минимизировать риски", и посмотрим на текст через призму здравого смысла и баланса интересов.

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

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

✅ Сегодня начнем с Преамбулы и Принципа №1 "Применение стандартов".

‼️ Призываю комментировать конструктивно. Задача не в том, чтобы поругать документ или авторов, а в том, чтобы найти ту самую "золотую середину", при которой и заказчик чувствует себя защищенным, и у исполнителя есть возможность работать предсказуемо и с адекватной маржинальностью.

Поехали! ⬇️

P.S. Если вы догадываетесь, кто автор — оставим догадки при себе. Важен именно документ и его суть

#Рассуждения_о_проектах

Итак...

Преамбула и Принцип №1 "Применение стандартов".

Без преукрас и первичных корректировок... Вот как есть...

✅ Преамбула
Для целей настоящего документа под «Исходными требованиями» понимаются требования к функционалу, составу, характеристикам и условиям эксплуатации автоматизированной системы, зафиксированные в Договоре и приложениях к нему, а также в иных письменных согласованиях Сторон, предшествовавших заключению Договора. Любые уточнения, дополнения или изменения Исходных требований оформляются письменно и могут являться основанием для корректировки сроков и стоимости работ.

⚠️ Принцип №1 "Применение стандартов"
Кратко:
Если есть конфликт интересов, и договор не дает ответ по ситуации, тогда Стороны обращаются к выбранному стандарту внедрения. Стандарт выбирается Сторонами совместно.

Для договора:
Вопросы, связанные с созданием, документированием, испытаниями и приемкой автоматизированной системы, не урегулированные действующими Договорами и иными согласованными Сторонами документами, разрешаются Сторонами с применением национальных стандартов Российской Федерации комплекса «Информационная технология. Комплекс стандартов на автоматизированные системы» (ГОСТ Р 59792-2021, ГОСТ Р 59793-2021, ГОСТ Р 59795-2021, ГОСТ 34.201-2020, ГОСТ 34.602-2020 и иные взаимосвязанные стандарты). При этом Стороны сохраняют право в рабочем порядке определять конкретные параметры и этапы реализации проекта, не противоречащие существу обязательств по Договору. В случае противоречий между условиями Договора и положениями указанных стандартов приоритет имеют условия Договора и согласованные Исходные требования.

💬 Давайте обсуждать

#Рассуждения_о_проектах

Здравствуйте.

☝️ Ранее мы затронули тему «Говорят, что 1С:ТКВ не применима… 😮😮😮»

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

〰️ Вспоминаю себя в начале карьерного пути.
На первом месте работы, слава Богу, была очень продвинутая компания в части управления проектами и там было все – и корп хранилища для проектов, и корп шаблоны и типовые формы документов и многое другое.
Потом была компания, где все только выстраивалось. Но зато там у меня уже была база, на которой можно «ехать». Взяла ее и стала применять ее в реалиях другой компании. Конечно, пришлось много переделывать и самое главное создавать с нуля! И вот тогда я думала «Ну где же взять хоть какие базовые шаблоны документов, хоть какое-то описание хода проекта?».

Знаете, наверно именно поэтому я сейчас и занимаюсь той работой, которой занимаюсь…

Так вот, искала документы, собирала проектные артефакты у команд, анализировала, делала шаблоны для компании.

И вот сейчас, когда подготовлены своды знаний, в которых много что есть, сталкиваюсь с тем, что:

1️⃣ Люди не хотят изучать. Мне кажется, это тот самый эффект, когда мозг сопротивляется обучению, как только может 🤯 Нормальное объяснимое состояние. Я его тоже часто переживаю 🥵

2️⃣ Еще люди, говорят, что слишком много написано ✏️✏️ ✏️✏️✏️. Ведь это надо прочитать 📕, над этим надо подумать 🥶, и надо взять в конкретный проект то, что нужно именно для него, проекта. И тут же, как будто прикрываются отрицанием «Мы не делаем так сложно, дайте краткий подходящий ‼️ВНИМАНИЕ‼️ на все случаи жизни подход».

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

⚡️ Где-то в проекте есть блок работ по «железу» - и тогда нужен целый блок специализированных документов.
⚡️ Где-то есть члены команды явно от бизнеса и явно от ИТ, тогда придется для упрощения согласования разделить методологическую составляющую проектных решений и технологическую.
⚡️ Где-то нужно проработать концептуальную архитектуру системы, т.к. много открытых вопросов, а где-то нет. Тогда могут появляться или пропадать документы «Концептуальный дизайн» и его обвязка.
⚡️ Где-то нужно все протоколировать, т.к. понимаем, что в проекте ну уж такой подход, а где-то есть понимание, что мы работаем с компанией «слова» и протоколы избыточны и даже раздражают.
Ну и так далее…

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

3️⃣ Еще одно отрицание, которое я слышу «Давайте сделаем уникальные индивидуальные технологии для отрасли или для объема клиента». Но тут возникают все те же вопросы, что я описала выше. Ведь в рамках отрасли или в рамках ниши, в которой находится наш клиент, существуют абсолютно разные компании – по культуре, по стилю, по потребностям – и в результате по проекту. И как же сделать «типовой» жизненный цикл проекта тогда?

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

Подскажите, поделитесь вашими мнениями ✏️
Я-то описала свое видение, свой подход, свою идею работы с технологиями.

P.S. У Фирмы «1С» есть разные технологии.
Их разница концептуально заключается в 2 вещах:
✅ В подходе к проектированию системы – проектирование и описание всей системы или работа с функциональными разрывами
✅ В объеме «бюрократии» - протоколов, отчетов …

#Технологии_1С

И вот правда☺️☺️☺️ даже в этом посте слишком много написано🙂🙂🙂

Убить взглядом – убить словом…
Демотивировать одним предложением…
Этакий кейс, но психологический

Добрый день.
Поделюсь своим, даже не знаю, как сказать - шоком, открытием, … 😮🥶😭☹️😖 причем, спустя годы...

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

Говорили о мотивации, демотивации, о том, как руководитель должен относиться к подчиненному… В общем, вспоминали былое…

И тут я слышу...

Лен, а помнишь ситуацию…

Я пришел к тебе поговорить, потому что понял, что больше не могу делать проект, ну вот все …. не-мо-гу.
Пришел и говорю: «Лена, я больше не могу управлять этим проектом, сними с меня полномочия РП.»
А ты отвечаешь, и так просто отвечаешь, без эмоций: «И что? Получается я его должна делать?»

И я думаю... вроде все логично: ну почему ты должна это грести за меня, и вроде всего одно предложение сказала, и не ругала, не критиковала, …. НО … для меня это был провал… прибило, придавило, ощущение безисходности…

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

Ведь, правда, вроде ничего такого не сказала…

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

И тут такой провал для меня, хоть и из прошлой жизни… 😭😭😭

Добрый день.
Продолжаем ранее начатую тему ⬇️

Хочу поделиться с вами интересным документом, который попал ко мне в работу. Это проект "Принципов внедрения 1С", сформулированных командой заказчика. Это не техническое задание и не смета, а именно попытка сформировать "правила игры".

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

⚠️ Принцип №2 "Документирование"

Кратко:
Заказчик обязан предоставить необходимую информацию, а Подрядчик должен отразить её в документах. Если Заказчик предоставил информацию, но Подрядчик не отразил её в документах, то это ответственность Подрядчика.

Для договора:
Подрядчик разрабатывает и представляет Заказчику на согласование проектную документацию, необходимую для выполнения работ по Договору и ввода автоматизированной системы в эксплуатацию.
Состав и объём документации определяются Подрядчиком исходя из необходимости обеспечить штатную эксплуатацию системы в соответствии с её функциональным назначением, определённым Исходными требованиями и утверждённым Сторонами перечнем работ.

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

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

Если после приёмки работ или в ходе эксплуатации выявится недостаточность документации для штатной эксплуатации системы в объёме, соответствующем утверждённому перечню работ и Исходным требованиям, и эта недостаточность не связана с изменением Исходных требований после утверждения перечня работ либо с предоставлением Заказчиком неполных или недостоверных исходных данных (при условии, что Подрядчик надлежащим образом фиксировал запросы на предоставление информации), доработка документации осуществляется Подрядчиком за его счёт в течение 30 календарных дней.

Подрядчик обязан не позднее 3 рабочих дней с момента возникновения потребности в информации направить Заказчику письменный запрос с чётким описанием требуемых данных и сроком их предоставления. Если запрос не содержит конкретики, позволяющей Заказчику однозначно определить необходимые сведения, Заказчик вправе запросить уточнение, и течение срока ответа приостанавливается до получения уточнения.

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

💬 Коллеги, давайте обсуждать

#Рассуждения_о_проектах

Γειά σου, коллеги

Все не дает покоя мысль про технологи 🤕

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

А что такое вообще технология?
И, скажу честно, когда начинала писать ТКВ, я называла ее (ТКВ в смысле) методологией.

И мне подумалось, а может быть здесь кроется какая-то часть проблем. Ведь, как известно, «как корабль назовешь так он и поплывет».

Обратилась к все набирающему популярность ИИ 🤖

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

Далее проанализировала ваши ответы на мои вопросы о применении ТКВ. И ведь там были четкие ответы: в ТКВ нет инструментов, ТКВ не инструкция.

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

На самом деле получается, что ТКВ это скорее не технология, а методология – рекомендации как организовать проект, как делать проект, как контролировать ход проекта.

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

Вот это открытие! Точнее не открытие, а окончательное осмысление терминов, которые мы используем.

Как вы считаете, корректно ли я рассуждаю? ✍️

#Технологии_1С