1. Однобокость. Текущие цели не охватывают деятельность всей компании, команд: что приведет к рассинхрону между отделами в дальнейшем, низкой продуктивности из-за того, что каждый «тянет» в свою сторону, по своим «целям». Потеряем в общем понимании, куда идем, в фокусе, и конкурентоспособности.
2. Путание метода достижения и результата достижения: целей и задач. Складывается такое впечатление по формулировкам типа «сделать и внедрить проект». Это невольно нас ведет к ошибке в мышлении, с парадигмы 100% уверенности того, что сделанные проекты принесут желаемый результат. Поэтому в best practices формулируют желаемый результат, а далее ставят гипотезы-решения, которые вероянто могут это принести. С учетом того, что могут оказаться неправы, и придется менять план.

Альтернатива и решения:

• Мой пример OKR https://prnt.sc/n4oFmOFknWFE
• еще: https://x.com/i/grok/share/dwHtCVoc7O8lRjjLWNG1KvGzH
• Нужно понимать, зачем нужен метод в первую очередь. В моей понимании зачем это:
1. синхронизировать отделы для того, чтоб в этом объединенном потоке, находить узкие места, и работать над расширением этих узких мест, тем самым, увеличить результат: как по деятельности компании, так и ее финансовым успехам.
2. управлять в течении года вниманием всей компании на этой цели: чтоб идеи, решения, действия, были в соответствии с этой целью.

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

Мой «контраргумент» комментариям Кирилла и Алексея про прибыльность "бизнеса".

Если поставим во главу пользу(ее объем), команде/компании придется разбираться, что является пользой. В каждом продукте, определять это. Слова «автоматизация» не дают такого понимания, это средство, а не польза. Польза — это сэкономленные ресурсы, удержание прибыли, которая могла бы быть потеряна, увеличенное количество жизни человека, возможности и так далее.

Говорить об этом легко, но чтобы ее реально принести, думаю нужно уметь в первую очередь «приносить много пользы», а не «много подписок продавать». А если сейчас не умеем, то быстро учиться ее приносить, учитывая и будущее время. Ставим во главе угла пользу, а далее, да, как условие для жизнеспособности сейчас и в будущем, учимся тому, как сделать так, чтоб это было еще и жизнеспособно: продавать, контролировать расходы, и пр. необходимые вещи, для финансового успеха.

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

Цель заработать может быть у личностей, но у компании должна был причина, почему она существует: если только заработок, то это возможно мошшеничество, фрод.

Еще проблемы, когда ставите во главу угла прибыль:

• это трансформирует команду, ее внимание на извлечения этой прибыли(собиранию сливок), вместо трансформации нанесения большой пользы миру, среде.
• я не против собирания сливок, но считаю, что если принести пользу, будет больше шансов получить что-то обратно. Если научимся делать это лучше других, рынок будет наш. А не наоборот.
• Пример падения OpenAi

Критика самих «утвержденных» тезисов:

Революция на фарм-рынке: для чего она? Революций не делают просто так, мы это знаем, а революцией хотят что-то изменить, make a difference. А финансовые ресурсы, играют роль инструментальную, является условием, но не самоцелью для компании.

Заявление о себе на рынке: для чего оно? Как измениться жизнь людей от нашего "заявления"? Она только эгоистичная, самохвальная. В таком лично мне неинтересно участвовать. Положительно влиять на жизнь людей, да, в этом хочется участвовать.

Критика подхода целеполагания OKR в целом:

• Когда CPO предлагает оценить достижимость целей, без определения границ целей, это во мне рождает сомнение касательно правильности подхода, или понимания целеполагания коллегами. Поэтому делюсь своими сомнениями сразу на месте.
• Когда консультант по HR презентует, думаю, важно проговаривать не только что такое метод OKR, но и проговаривать зачем этот метод нужен, какие слабые места метод имеет: https://x.com/i/grok/share/dwHtCVoc7O8lRjjLWNG1KvGzH
• на текущий момент, на мой взгляд, она это плохо понимает. Но дело даже не в ней, потому что консультанты не кладут "шкуру на кон", поэтому могут принимать неосторожные решения, т.к. последствия их не коснутся настолько, насколько коснется это того, кто послушается и примет решение на основе "совета".

1. Как менять цены номенклатуры в 1C,
2. ссылка
3. Почему у меня не видно id-шки? Как можно выводить поля в табличках. Вот так поля можно выводить: https://screenrec.com/share/nvD0aP9fNY

CRM и 1С/УТ(система управленческого учета) не одно и тоже!

В 1С много «подстраховок». Даже изменение цен, фиксируется как документ, с историей - то есть описание самой команды и оно сохраняется исторически, включая кто её создал. А после, чтобы команда стала «действительной», её нужно ещё и «активировать» - провести.

Сделанные работы в «учетке» по наведению порядка:

1. Структуризировал номенклатуру
2. Вынес архивные позиции в отдельную папку «OLD (архив)»
3. Пере-назвал согласно модели продукты, услуги. Не удалял!
4. Добавил около 60 недостающих позиций по тарифам
5. Добавил в позиции цены (там где есть)
6. Поправил типы номенклатур, их единицы измерений.
7. Оставил актуальные номенклатуры в папке* «Актуальная номенклатура (2024)»

Работы по проверке документов по FA-GOLD - 15 компаний:

1. Проверил документы продаж
2. Проверил документы поступлений
3. Если эти документы отстутсвуют, отмечаю в документе - соответствует правде/несоответствует.

17/11/24

Попытка сделать диаграмму, заметки

• «серия» - категория, фильтр, по которому можно выбрать разрез → «то, что справа»
• «точки» - это объект, сущность, которую рассматриваем, смотрим так же →какой-то разрез

• «значение» как раз и сущность, в его кол-венном выражении.

Можно ли добавить эту диаграмму на начальную страницу всем?

Можно вроде вывести. Найти можно в спец.функциях, в отчетах

Настройка интерфейса всем в 1С, или УТ:

https://youtu.be/ISK7xllforQ?t=33

Задача:

• за 1-3 часа поднять кругозор по теме, вооружится инструментами и начать делать.

https://habr.com/ru/articles/748228/

Ключевые обязанности QA-инженера

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

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

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

Документирование багов. Описывая баги, важно предоставить максимум информации об их природе и причинах возникновения.

Составление отчетов. Финальным этапом в работе тестировщика является составление отчета о количестве выполненных тестов, их результаты, определенные метрики и общий вердикт о целесообразности выпуска продукта в текущем состоянии с точки зрения ответственного за его качество.

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

• логи отправление, при случае багов
• скринкасты, скриншоты.

• баг репорт: дефект без документации = нет дефекта. Нужна документация дефекта, то что не документируем, считаем не найденным.
• Атрибуты баг-репорта:
• краткое название.
• название проекта
• компонент приложения - в какой части функциональности произошла
• номер версии
• Критичность. Этот атрибут показывает влияние дефекта на функциональность системы. Например:
• Blocker — дефект, блокирующий использование системы.
• Critical — ошибка, которая нарушает основную бизнес-логику работы системы.
• Major — ошибка, которая нарушает работу определенной функции, но не всей системы.
• Minor — незначительная ошибка, не нарушающая бизнес-логику приложения, например, ошибка пользовательского интерфейса.
• Trivial — малозаметная, неочевидная ошибка. Это может быть опечатка, неправильная иконка и т.п.

• Приоритет — high, medium, low.
• Статус. Статус исправления бага — to do, in progress, in testing (on QA), done. В зависимости от особенностей проекта возможны дополнительные статусы.
• Автор баг-репорта.
• На кого назначен. Баг-репорт отправляют тимлиду проекта или разработчику, который будет заниматься исправлением дефекта, в зависимости от принятых в команде договоренностей.
• Окружение. Где найден баг: операционная система, наименование и версия браузера.
• Предусловие (если необходимо). Необходимо для описания действий, которые предшествовали воспроизведению бага. Например, клиент авторизован в системе, создана заявка с параметрами ABC и т.д. Баг-репорт может не содержать предусловие, но иногда оно бывает необходимо для того, чтобы проще описать шаги воспроизведения.
• Шаги воспроизведения. Один из самых важных атрибутов — описание шагов, которые привели к нахождению бага. Оптимально использовать 5-7 понятных и кратких шагов для описания бага, например:
  1. Открыть (...)
  2. Кликнуть (…)
  3. Ввести в поле А значение N1
  4. Ввести в поле B значение N2
  5. Кликнуть кнопку «Calculate»
• Фактический результат. Что произошло после воспроизведения указанных выше шагов.
• Ожидаемый результат. Что должно произойти после воспроизведения шагов тестирования, согласно требованиям.
• Прикрепленный файл. Логи, скриншоты, видеозапись экрана — всё, что поможет разработчику понять суть ошибки и исправить ее.

Инструменты для QA

Jira

• Создание багов.
• Подключение к релизам.
• Релизы - это выпуск новой версии приложения, исправления в "актуальную" программу. Возможно текущий биллинг придется тоже версию назвать: и сформировать план вокруг этого релиза → проведенные исправления.
• Спринт - это 2-ух недельный срок, "забег" работы команды.

История

История → одно большое приложение трудно поддерживать, менять и пр.

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

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

Микросервисы = API

Каждый сервис должен иметь свой API, по которому ему можно "обратиться". Чтобы он сделал какую-то задачу.

Общаться сервисы могут через HTTP или gRPC запросы. Такой способ называется синхронной коммуникацией.

An application programming interface (API) is a way for two or more computer programs or components to communicate with each other. https://en.wikipedia.org/wiki/API

Вывод:

• Микросервисы - сложно, дорого.
• Не всегда могут сработать.
• Нужны серьезные "за", чтобы переходить.

DevOps

https://www.bmc.com/blogs/devops-culture/

• Lucid map

To-do:

Прям раскладываем эти красные блоки, нумеруем, берём в проверку, самими, сотрудниками.

Для чего нужны в первую очередь описания сценариев:

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

Разница между Use case vs User stories:

Ещё примеры:

• https://uxcam.com/blog/user-stories-vs-use-cases/#:~:text=Use%20Case%20vs%20User%20Story%20%2D%20Key%20Differences&text=User%20stories%20are%20expressed%20in,in%20format%20with%20multiple%20sections.&text=User%20stories%20are%20centered%20around,goals%20of%20the%20end%20user.
• https://www.figma.com/resource-library/what-is-a-use-case/

Список ошибок по составлению:

по видео: https://youtu.be/Rur5DEoqDdM?t=750

1. В описании нет "вещь", с которой роль исполняет действия, использует - нет "объекта-системы" в описании
2. В описании нет "основной роли" - основного действующего лица.
3. Слишком много деталей интерфейса пользователя (тут не согласен = нет описания, нет договора). От неё ремарка: "в качестве общего описания, это ошибка, такое делается уже в реализации с тех.отделом". Что я и предполагал. Получается не пишем слишком подробно интерфейс ещё, чтобы и ограничения по реализации не ставить так же.
4. Описание низкого уровня. Нужно чуть группировать. Пример: описание когда пользователь вносит несколько типов данных: не разбивать на части, каждой строкой, а сгруппировать - "вносит _____-ието данные: 1, 2, 3"
5. Не прорабатывают расширения. "Расширения" — то, что может пойти не так.
6. Не указывают альтернативные сценарии. "Альтернативные сценарии" — то, что приведёт к успеху другим путём.
7. Считают что Альтернативы = Расширения.
8. Забывают про предусловия и тригеры.
9. Относятся к системе как к "черному ящику". (Малик: другими словами обсуждают её архитектуру, внутренность устройства, а не то, что хотят получить от объекта в первую очередь функционально, ещё не обращая внимания на архитектуру. Пункт 3 тоже в ту сторону.)
10. Не реализуют нумерацию шагов.

wikipedia:

Уровень детализации

Алистер Коберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:

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

Шаблон сценария

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

• Имя сценария. Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше, чем Регистрирующийся Пользователь), и должно объяснять смысл сценария использования. Неплохо использовать имя сценария, цель актора, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя. Пример: UC-1. Регистрация в личном кабинете.
• Цель. Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком акторе, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
• Акторы (действующие лица). Актор — это кто-то или что-то вне системы, влияющий(-ее) на систему или находящийся(-ееся) под её влиянием. Актор может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими акторами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия.
• Заинтересованные лица (Стейкхолдеры). Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования.
• Предварительные условия. Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте также, что предварительные условия это не «активаторы» (см. ниже), так как верные предварительные условия НЕ инициируют выполнение сценария.
• Активаторы. Активатор — это событие, инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), а ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.
• Есть несколько вариантов, как описать ситуацию, когда активация происходит, но предварительные условия не выполнены.
• Один путь состоит в том, чтобы обработать «ошибку» в пределах сценария (как исключение). В принципе такой подход нелогичен, потому что «предварительные условия» — теперь не истинные предварительные условия вообще (потому что поведение сценария определено, даже когда предварительные условия не выполнены).
• Другой путь — поместить все предварительные условия в активатор (так, чтобы сценарий не выполнялся, если предварительные условия не выполнены), и создать отдельный сценарий, описывающий проблему.
• Порядок Событий. Как минимум, каждый сценарий использования должен описать типичный ход событий, часто представленный как ряд пронумерованных шагов.
• Альтернативные пути и дополнения. Сценарии использования могут содержать вторичные пути или альтернативные сценарии, которые являются вариантами основного. Каждое проверенное правило может привести к альтернативному пути, и, когда правил много, количество альтернативных путей возрастает, приводя к очень сложным документам. Иногда лучше использовать условную логику или диаграммы, чтобы описать сценарии со многими правилами и условиями.
• Бизнес-правила. Бизнес-правила — способ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.

Ограничения сценариев использования

• Сценарии использования плохо подходят для документирования требований, не основанных на взаимодействии с системой (таких как алгоритм или математические требования), или нефункциональных требований (такие как платформа, производительность, синхронизация, безопасность).
• Следование шаблонам не гарантирует качество сценариев. Качество зависит только от навыков создателя сценария.

Может интегрироваться с корпоративными ERP, CRM, Бухгалтерскими программами, платёжными узлами.

SaaS Биллинг

Зачем ещё нужен АСР:

• компания предоставляет комбинированные, или конвергентные услуги.

Billing and Revenue Management

• Charging
• Billing
• Balance management
• Customer management
• Business intelligence and reports

Документ концепта биллинга: https://docs.google.com/spreadsheets/d/1nTIDMIzYDImkFrgQma5xfJAepavQ8AV8w5GEaAJmkvw/edit?gid=201352122#gid=201352122

Процедура расчета

в FOM - Prepaid - форма оплаты, оказания услуг - то есть, аптеки делают предоплату для использования услуг - пользование ПО на период

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

Use case, Use case vs User Scenario

Изученные ссылки:

Use case, Use case vs User Scenario

https://www.youtube.com/watch?v=SwBNhvfK8y0&t=24s

https://ru.wikipedia.org/wiki/%D0%A1%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B9_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F

https://habr.com/ru/articles/699522/

https://www.youtube.com/watch?v=9dOFSY5PoNo&t=3s

Billing systems

https://tridenstechnology.com/what-is-billing-and-revenue-management-brm/

https://tridenstechnology.com/best-subscription-management-software/

https://te-net.io/etapyi-vnedreniya-billinga/

https://tridenstechnology.com/what-is-billing-and-revenue-management-brm/

billingSaaS

https://fw-t.ru/articles/billing-v-2022

https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%91%D0%B8%D0%BB%D0%BB%D0%B8%D0%BD%D0%B3

https://ru.wikipedia.org/wiki/%D0%91%D0%B8%D0%BB%D0%BB%D0%B8%D0%BD%D0%B3

https://www.ixbt.com/mobile/review/billing.shtml

https://xn--90aeoaoap.xn--p1ai/billing-system-basic-concepts/

https://tridenstechnology.com/ru/%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B-%D0%B1%D0%B8%D0%BB%D0%BB%D0%B8%D0%BD%D0%B3%D0%B0-101-%D0%B2%D1%81%D0%B5-%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D1%8B-%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5/

billingsaas

https://xn--90aeoaoap.xn--p1ai/billing-system-the-basic-principles-of-work/

https://www.chargebee.com/resources/guides/saas-accounting-guide/

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

Собранность

• Минимизация усилий. Оптимизация затрат.
• Определение степени качества результата
• Минимизация объема работ.
• Минимизация количество информации: для выделения и обработки важного, но не всё.
• Убытки. Ресурсы. Как для компании, так и для личности.

Основной принцип в проектах, деятельности:

1. минимизируем ненужное / плохое (пример - лишние встречи)
2. потом уже занимаемся максимизацией нужного, например качества важных работ

В моем кейсе: убираем кол-во ненужных вечерних встреч, работы "за других", потом максимизируем важное: обучение 4 часа утром, составление концептов, определение критических цепей, узких мест.

Хотели и желания vs реальность, с реальностью ограничению по времени.

• способность трудиться
• выявление скрытых работ
• минимизация числа выполняемых работ

Чтобы справиться со скрытыми работами, надо вывести их во внимание: записать в экзокортексе и начать отслеживать.

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

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

Собранность

• Минимизация усилий. Оптимизация затрат.
• Определение степени качества результата
• Минимизация объема работ.
• Минимизация количество информации: для выделения и обработки важного, но не всё.
• Убытки. Ресурсы. Как для компании, так и для личности.

Основной принцип в проектах, деятельности:

1. минимизируем ненужное / плохое (пример - лишние встречи)
2. потом уже занимаемся максимизацией нужного, например качества важных работ

В моем кейсе: убираем кол-во ненужных вечерних встреч, работы "за других", потом максимизируем важное: обучение 4 часа утром, составление концептов, определение критических цепей, узких мест.

Хотели и желания vs реальность, с реальностью ограничению по времени.

• способность трудиться
• выявление скрытых работ
• минимизация числа выполняемых работ

Чтобы справиться со скрытыми работами, надо вывести их во внимание:

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

Внимание

• Аналогия - сенсомоторные датчики камеры

Агент

• "Камеры" агента - внимание агента: личности, команде, коллективу, сообществу.
• аппарат восприятия агента субъективен. Поэтому при рассмотрение одного объекта, этот объект у разных агентов может восприняться по-разному.

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

произвольное, понятийное внимание - S2 по Канеману

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

Свойства внимания

• устойчивость, бесперебойность
• объем
• рассеяность (деконцентрация, либо слабая физическая способность к концентрации)

Функции внимания:

• концентрация, деконцентрация
• распределение внимания(аппаратов восприятия)
• переключаемость (отвлекаемость)

Фокус внимания - граница, фрейм, обращенные камеры

Куда направлено ваше внимание – там, как правило, будут и результаты. Но если ваше внимание будет распределено между слишком большим числом проектов, многими хобби и увлечениями, то у вас не будет толком результатов, потому что у вас отсутствует фокус.

Оказалось, что реальный убийца №1 – это сердечно-сосудистые заболевания (30,2% смертей), на втором месте рак (29,5%).

Убирая многозадачность и многопроектность, получаем:

• быстрее прогресс, результаты
• увеличение производительности труда без затрат (буквально работаем меньше, но над самым важным, по принципу Парето),
• Уменьшение числа переключений – снимается лишняя когнитивная нагрузка.

Меньше переключений = больше производительность труда без лишних затрат.

Ускорение можно ещё получить:

• убрав отвлечения: внутренние, внешние
• внешние - убираем уведомления, возможность нас "достать".
• внутренние отвлечения - нехватка ресурсов на выполнение задачи, новые мысли приходящие,

Где схема логики торговли типовой организации в УТ.

Логика торговли - схема. Пример:

Поможет логику понять и сотрудникам, и одно видиние иметь для менеджеров/разработчиков.

Документ "Реализация товаров и услуг" это документ "продажи". То есть, когда мы создаём документ "Реализации товаров и услуг", мы оформляем в своей учетке компании - запись о том, что мы продажи кому-то что-то. То есть, это обязательный документ в первую очередь для учета, а в случае FOM и для авто-включения услуги нашим софтом.

Нужен общий концепт софта сформулировать. Описание логики, функции. От которой уже далее отталкивать изменения, и все инкременты.

Настройка панели навигации:

https://www.youtube.com/watch?v=2hMbK9IKXg4

Как понимаю, у нас работа начинается с «Поступление безналичных ДС(денежных средств)".

НСИ (нормативно-справочная информация) – данные из справочников классификаторов и записи, которые вводят пользователи системы. Для построения и использования единого информационного пространства компании разработаны решения по централизованному ведению НСИ в 1С

Что изучаю:

1. Составлять регулярно 2 модели:
1. Balance sheet (Баланс)
2. Income Statement(Net Income)
2. Нюансы: что к чему, как составлять, стандарты, чего избегать в практике.

Зачем:

1. Составлять более полезную управленческую отчётность для компании
2. Наладить личные активы, как в качестве инвестора, так и в качестве компании.
3. Принимать более правильные управленческие решения, как на уровне компании, так и на уровне личных активов/обязательств
4. Видеть основные приоритетным проблемам компании, действовать по их устранению.
5. Увеличить виживаемость, процветание, развитие организации/бизнеса/компании.

Что нужно будет сделать:

1. Практика.
1. Составляем личные модели Net income и Баланс (в определенный отчётный период - месяц/квартал/год - решить)
2. Составляем модели Net income и Баланс для организации, в купе с фин.анализом по Баффету и Питеру Линчу - от Алишера (google drive c материалами). Организации:
1. FOM - приоритетно, для менеджмента, инвесторов, себя(своей лучшей продуктивности)
2. Valikhodjaev Gallery House
3. Семейный баланс
4. Bellissimo
2. Обучение других
1. Составить базовое введение в эту тему для членов семьи. Чтобы закрепить материал.
3. Пропитка
1. прочесть 2 книги google drive c материалами для понимания основных стратегий и получения кругозора

2 части заметок:

1. Самостоятельное изучение составления Баланса и Net Income, немного фин.анализ и основных 90% понятий с бухгалтерии.
2. Презентация и рассказ Алишера (это по времени произошло первым) по фин. анализу, как анализовать компанию, чтобы принять решение - инвестировать или нет.

Ниже заметки с самостоятельного обучения (ещё под ними есть, от презентации Алишера):

⁠https://ramp.com/blog/how-to-make-a-balance-sheet⁠⁠ещё к баланс шиту можно добавить income statement and cash flow statement( возможно он внутри же будет)

В целом, баланс — это снимок текущей ситуации.

At its essence, an accounting balance sheet is one of the most accurate ways to analyze the company’s financial position. When fleshed out, a balance sheet can show you:What the business ownsWhat the business owes‍How much has been invested into the company
(https://online.hbs.edu/blog/post/how-to-prepare-a-balance-sheet⁠)⁠managers-guide-to-finance-and-accounting.pdf⁠⁠⁠A-Guide-to-Advancing-Your-Career-with-Essential-Business-Skills.pdf⁠⁠

What’s the difference between a balance sheet and an income statement?

An income statement, also called a profit and loss (P&L) statement, lists out a company’s revenue streams (such as sales) and expenses (payroll, operating expenses, etc.) over a given period of time.

‍

A balance sheet, on the other hand, covers a company’s assets (cash, outstanding receivables, securities, inventory, etc.) and liabilities (outstanding payables, debt payments, taxes, rent, etc.) at a certain point of time. ‍

То есть, своими словами — Нет инком — это движение и уход, снимок потоков финансов - приходящих, уходящих.

Баланс — снимок того, что имеем. Включая то, что должны другим на текущий момент. Что накопилось, и что должны.

equity - капитал — финансы, которые остаются в свободном пользовании — изшлишки

Состояние средств на счете в текущий момент.

⁠

⁠Справочник по колонкам

⁠

⁠

Инструкция по составлению Балансовой таблицы:

Выбрать регулярный день отчёта.

Step 2: List all of your assets

​Разница между Дебетом и Кредитом в Балансе

⁠

⁠

⁠

Balance Sheet Basics

⁠

⁠⁠

Баланс, это как снимок — текущей ситуации организации. Если рассматривается организация.

⁠

⁠⁠

Активы/Assets/Ресурсы (равно) Обязательства(то, что компания заняла) + Equity (средства, те, что акционеров)

Почему так, Активы/Assets/Ресурсы это то, чем компания владеет. Если дали в долг, использовать, то можем считать, этот ресурс во владении компании, она этим ресурсов владеет.

⁠

⁠⁠⁠

⁠⁠⁠

⁠⁠

⁠

⁠⁠

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

То есть, это относится к Дебиторке — подсчёт не только финансовых движений, но и дебиторки.

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

Счёт-фактура нужен для учёта налогов и во время передачи товаров или услуг.

Счёт на оплату работает в качестве сообщения покупателю с указанием суммы, которую ему нужно заплатить.

Квитанция выдаётся продавцом, чтобы подтвердить оплату.

Инвойс играет сразу несколько ролей в финансовом управлении предприятием:

подтверждает факт сделки между поставщиком и покупателем;

является основанием для выставления счёта на оплату;

участвует в учёте доходов

⁠

и расходов

⁠

, формирования отчётности и расчёта налогов.

⁠

⁠⁠Deffered Revenue — Предоплата, за услуги, которые мы ещё не реализовали

Transaction flow

⁠Financial statement

⁠

(Финансовые статьи?. В переводе Финансовый отчёт, Финансовая ведомость)

⁠

⁠⁠

журналы учета

Журналы учета, это реестры, базы данных про какие-то объекты, их объем в организации.

⁠

⁠⁠Логика такая, что то, что мы одалживаем, записываем в статью, как то, что мы имеем, чем теперь обладаем. В виде стоимости.

Dr (Debit record), Cr (Creditrecord) - As a matter of accounting convention, these equal and opposite entries are referred to as a debit (Dr) entry and a credit (Cr) entry. For every debit that is recorded, there must be an equal amount (or sum of amounts) entered as a credit.

⁠https://www.colorado.edu/controller/content/journal-entry-debt-credit-convention#:~:text=DEBIT%20AND%20CREDIT%20CONVENTION&text=As%20a%20matter%20of%20accounting,amounts)%20entered%20as%20a%20credit.

⁠

⁠

Transactional statement

Заработанное, записываем в Liability - т.к. это то, что должны отдать акционеру, инвесторы, владельцу.

⁠

⁠⁠Отношения Income Statemend (Net Income) и Баланса

Метафора: Income Statement - это про события, которые происходили - внимание на потоки, движения, Balance sheet - итоги событий, где они закончились, или итоги событий на момент

DSO или Days sales outstanding, также встречается названия days receivable, average collection period, average debtor days) — показатель, используемый компанией для оценки объёма непогашенной дебиторской задолженности. Равен отношению количества дней в отчётном периоде к оборачиваемости дебиторской задолженности.

⁠Срок погашения дебиторской задолженности - Википедия

⁠

⁠

заметка по дебиторке:

Думаю стоит ввести и DSO

⁠

() метрику в KPI - средний срок погашения дебиторки. Чтобы стандарт иметь, и какой-то из отделов выполнял план по нему, обращал внимание. Формула рассчёта

⁠

⁠

Учет амортизации знаний - Depreciation. Почему важно не забывать о Depreciation - знаний? Так как из внимания важно не потерять, что знаний, тоже Asset. Замечая это, мы будем правильнее решения принимать по знаниям — какие имеем, какова их ценность текущая, какие знания хотим привлечь.

То есть, происходит Knowledge Management в организации: в купе все знания/методы/подходы(описания), и как с ними работают, как практикуют, используют. Что компания использует, как метод, а что нет.

⁠

Подсчёты по стандартам GAAP/IFRS

⁠GAAP principles

⁠

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

Метод расчёта в бухгалтерии: Cash accounting and Accrual accounting

⁠

(GAAP/IFRS)

Их разница - бухгалтер говорит, есть разница между ними — cash для более начальных периодов в компании, Аккруал для более уже выросших, которые стартанули ссылка на объяснение

⁠

⁠

Cash accounting — расчёт по факту, когда финансы поступили — у нас я думаю называют это Cashflow

Accrual accounting — расчёт с учетом дебиторки, как нашей, так и кредитов, заключенных договоров(как я понял). У нас это называют P&L.

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

⁠GAAP for Investors

⁠

⁠

accrue allowance in accounting — начислить резерв в бухгалтерском учете. Те резервы, которые покрывают рискованные дебиторки, которые имеют риск списания.

Риски по поставщикам, крупным, о них сообщать инвесторам по принципу GAAP

⁠

.

Accrual Liabilities - The term "accrued liability" refers to an expense incurred but not yet paid for by a business. These are costs for goods and services already delivered to a company for which it must pay in the future. A company can accrue liabilities for any number of obligations and are recorded on the company's balance sheet.

⁠

Assets Analyis. Part 5

Company Cash Runway

⁠

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

8 Questions to analysis:

Cash. Does the company the company have sufficient cash on hand to pay its bills?

Accounts Receivables (дебиторка). Does the company has collection issues? (DSO является индикатором размера проблемы).

Inventory. Is there any stale inventory on the books? Inventory Aging Schedule.

Property, Plant & Equipment. Is there any obsolete equipment? (вышедший из употребления, устаревший, непотребный). Оцениваем крупные активы, если процент неиспользуемого большой — делаем корректировки в активах. Есть вероятность, что активы раздуты, используемые.

Accounts Payable. Do we owe suppliers longer then 90 days? Accounts Payable Aging. If company has AP longer then 90 days, for major invocies, then compay nor has issues with managing cashflow, or has real operational issues.

Deffered Revenue. Are we expected to deliver these goods and services? As the breakdown of customer/product. Check, iquiry about capability of delivering from the management. Keep in mind that if they will not, they are going to pay back Deffered Revenue to their customers back.

Shareholder`s Equity. Have the owners invested enough capital of their own capital? The Capital Table. Does the equity include contribution from the founders/owners? It is strong bullish sign on the business to see the owners investing their own money in the business, and the opposite is also true

Long Term Debt. Does the company have too much debt on its books? Key Metric: Debt/Equity Ratio (Industry Benchmark)

⁠. Если хотим сфокусироваться на каком-то обязательстве, то к примеру, соотношение можем сделать с ним же

⁠ - получим - долг/заработок (равно) — кол-во времени требуемое для выплаты. Смотрим бенчмарк.

inflated

⁠distended

⁠

through being filled with air or gas. Example - "a partially inflated balloon"

⁠excessively

⁠

or unreasonably

⁠

high. Example - "inflated salaries"

⁠

Chapter 7 - Common Mistakes of the Balance sheet - Checklist

Not Balanced! Balance sheet.

Assets/Liabilities missclassified. Неправильно классифицированы - распределены статьи по активом и обязательствам. То есть, засунуты не в те места.

Long/Short term missclassified. Неправильно классифицированы - распределены статьи по активом и обязательствам но уже в долгосрочности и краткосрочности — определении. То есть, засунуты не в те места.

Valuation mistakes. Ошибки оценки, расчётов. Нужно проверять, поэтому.

Бонус шаг

Как решать, избегать этих ошибок:

Not Balanced! Тут должна быть точка зрения компании. У компании нет “своих” денег, если есть свободные средства, то они принадлежат инвестору и должны ему быть отданы в распоряжение. А обязательства, организация должна третьим лицам: поставщикам, клиентам, кредиторам и пр.

⁠⁠

⁠⁠Assets/Liabilities missclassified.

⁠⁠Long/Short term missclassified. Проверка по срокам - если обязательство на менее 12 месяцев, тоь это current Liability(обязательство), если более 12, то Long Term Liability, долгосрочное обязательство. Отсчитываем от даты составления Баланса. Обновляем, если даты меняются, переводим статьи, актуализируем по их расписанию.

⁠⁠Valuation mistakes. Ошибки по расчёту:

Для дебиторки, не создаём Allowance for Doubtful Accounts

⁠

- предположение, сколько дебиторки не сможем вытащить, придется списать. То есть, мы по сути, должны снижать размер дебиторки — так как какую то из дебиторки не получится реализовать.

Inventory

Не списанные ресурсы, поломанные, вышедшие из строя, срока годности

Не оценивания ресурсов, инветаря по “сниженным ценом” или по NVR

⁠

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

⁠Intangible Assets

⁠

- не пересмотренные нефизические активы - роялти, репутация, бренд и пр (patent, brand, trademark, or copyright. Businesses can create or acquire intangible assets. An intangible asset can be considered indefinite (a brand name, for example) or definite, like a legal agreement or contract.).

нет пересмотра ценности этих активов по текущему рынку -Fair market value (FMV)

⁠

⁠

⁠

⁠⁠Связанное с третьим пунктом — не обновление данных задолжностей по балансу, цифры по ним. Поэтому в каждом отчётном периоде, нужно перепроверять эту цифру на верность

Advanced: курс к покупке, или прохождению (возможно компания захочет купить) https://controller-academy.com/courses/controller-academy#pricing

⁠

Заметки, Алишер:

To-do:

1. Посмотреть материалы, которые отправил Алишер → фундаментальные (google drive c материалами).
2. Сделать резюме, поделиться с Тимой.
3. Составить свой Balance sheet
4. Скачать, посмотреть шаблон Алишера.
1. Сделать анализ через шаблон свой личный, FOM, Bellissimo.

Различие компании и человека

Что такое организация?

1. Организация  - люди, компания люди.

Будем ли мы успешны? Нужен подход, стратегия, методика. Теоретическая часть.

Компания →

Когда покупаете акции, часть → надо думать не покупки части при покупке части, а надо думать, что вы покупаете всю целую часть компании → чтобы оценивать всю компанию, думать как о целой компании.

Готовы ли вы вложить ваши деньги в эту всю компанию? свои 1000;. Это основа рассмотрения, основная парадигма.

2 парадигма:

покупка части компании навсегда, с учетом какого-то кризиса раз в 10 лет. Который обычно 2-3 года будет приходить в себя, то есть наличие подушки должно быть. Чтобы забыть деньги, которые вкладываются, можно было их забыть → можно воспринимать как “налог” который платишь в государство и забываешь о нём. Мне важнее не выйти из игры.

Метрика:

• Price Earning Ratio. Надо учитывать.

6 категорий компаний. По Питеру Линчу:

1. Slow Growers.
2. Stalwarts.
3. Fast Grower.
4. Cyclicals - сезонный бизнес. Если не учли то, что цикличность своя падает, и уже то, что было сделано, не то, что имеет смысл быть. Нет новой волны. Цикл продукта заканчиваются.
5. Turn Around. Те, кто вышли из игры. Камбэкнувшиеся. У них тоже есть шанс, так как есть эффект “мышечной памяти”. У них остались хорошиеспецы, методыдология, фундамент, который позволяет компании в нужную сторону перенаправить, сделать Пивот.
6. Asset Plays. Много недвижки, ценностей, в виде земли и пр., - активы сами по себе высокой стоимости.

Характер компаний. Поэтому нельзя мерить одной метрикой 2 компании.

2 основных отчёта, которые можно узнать за 30-40 мин и составить

1. Net income
2. Основные метрики, ratio, бенчмарки от типа бизнеса по 6 типам.
1. Revenue позволяет посмотреть на реальную ситуацию. Revenue. Мысль Питера Линча: «Если бы я могу смотреть только на 1 метрику организации, я бы смотрел только на Revenue. По ней я бы смог понимать реальнее ситуацию». MFG - если растёт пропорция, то плохо. Если растёт, то хорошо.
2. Нераспределенная прибыль — если она остаётся, излишек, то это очень хорошо.
3. Balance sheet
4. активы. Которые служат. Баланс sheet - это фотоснимок вашего состояния, ваших активов, так и обязательств. Сколько у нас, какой состояние.

можно посмотреть 30-40 мин., видео, где понять на 80% процентов, получить картину и получить все нужные результаты. Мелочи сильно не тратиться.

Equity - баланс.

Запись встречи(private link for myself)

Разница между Дебетом и Кредитом в Балансе