Русский
Русский
English
Статистика
Реклама

Финансы в it

Классификация критичности информационных систем

27.07.2020 10:17:57 | Автор: admin
Альфа-банк надежен, как танк,
А Гамма-банк надежен как банк!

Виктор Пелевин, Числа

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



Если посмотреть вакансии разработчиков в банке, то вполне можно увидеть там среди требований знания Cassandra, MongoDB и других платформ, которые никак не внушают мыслей о 100% доступности. Да и такие СУБД как Oracle или Microsoft SQL Server где-то устанавливают на кластер из дорогих серверов, подключённых к самым надёжным и высокопроизводительным массивам, а где-то на обычную виртуальную машину в ферме из самого что ни на есть commodity.

Причины очевидны избыточные решения дороги. Но как найти компромисс между стоимостью платформы и её надёжностью?


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

  • серверы класса hi-end с дисковыми массивами класса hi-end плюс синхронная репликация;
  • серверы класса midrange с дисковыми массивами класса midrange плюс синхронная репликация;
  • серверы класса midrange с дисковыми массивами класса midrange плюс асинхронная репликация;
  • commodity-серверы с дисковыми массивами класса midrange без репликации.

Как же теперь выбрать конфигурацию для конкретной базы данных, принадлежащей конкретному приложению?

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

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

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

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

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

  • Platinum;
  • Gold;
  • Silver;
  • Bronze.

Или так:

  • Mission critical;
  • Business critical;
  • Business operational;
  • Office productivity.

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

При оценке важно соблюдать два правила:

Систему оценивает бизнес, а не обслуживающее её подразделение IT. Критичность не должна определяться тем, насколько долго или трудоёмко обслуживание системы. Единственный критерий убытки, которые понесёт бизнес от простоя системы.

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

Что определяет уровень критичности?

  • Приоритет обслуживания при массовых инцидентах. Безусловно, любую систему нужно восстанавливать после аварии, но если авария задела несколько систем, то сначала нужно восстановить наиболее критичные.
  • Типовые значения SLA (service level agreement). Если простой системы приносит убытки, то правильный путь не жаловаться на администраторов, а повышать её уровень критичности.
  • Стандартные инфраструктурные решения. Каждое из перечисленных выше решений обладает определёнными характеристиками надёжности, обеспечивающими скорость восстановления при сбоях, а также определённой стоимостью.

В мировой практике сложилось примерно такое распределение:



Это не значит, что на вашем предприятии распределение систем по классам должно быть именно таким. Но в любом случае если в класс Mission critical попало больше 15% эксплуатируемых систем, это повод серьёзно задуматься.

На вопрос насколько нужна та или иная система, любой владелец ответит очень. Следовательно, нужно задавать другой вопрос: а что случится, если система остановится? Класс критичности системы зависит от тяжести последствий остановки системы и скорости их наступления.

Давайте рассмотрим несколько банковских систем.

Расчётная система обеспечивает (сюрприз!) расчёты между клиентами юридическими лицами. Если вдруг крупный корпоративный клиент не сможет сделать платёж контрагенту, то банк потеряет весьма существенную сумму, поэтому расчётная система, без сомнения, попадёт в высший класс критичности.

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

Теперь возьмём систему, которая ведёт вклады. Если остановится эта система, то убытки банка вновь будут невелики, а отказ в обслуживании не будет столь массовым, как в случае процессинга. Но нужна ли нам передовица в газете с заголовком Банк отказывается выдавать вклады? Вопрос риторический.

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

Итак, негативные последствия от простоя системы можно разделить на 4 класса:

  • Экономические (непосредственные убытки);
  • Клиентские (отказ в обслуживании);
  • Репутационные (негативные реакции в средствах массовой информации);
  • Юридические (от предупреждений и штрафов до судебных исков и отзыва лицензии).

Для каждого класса последствий следует сформулировать критерии тяжести и присвоить им оценки от 0 до 4. Например, таблица может выглядеть так:

0 1 2 3 4
Экономические нет <0.1% плановой прибыли 0.1%..0.5% плановой прибыли 0.5%..1% плановой прибыли >1% плановой прибыли
Клиентские нет 1 клиент >1% клиентов >5% клиентов >10% клиентов
Репутационные нет огласка маловероятна огласка в локальных СМИ огласка в региональных СМИ огласка в федеральных СМИ
Юридические нет предупреждения регуляторов штрафы регуляторов гражданские иски риск отзыва лицензии

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

Следующим шагом нужно выбрать временные интервалы, на которых мы будем оценивать убытки. Например, час, 4 часа, 8 часов, 24 часа. Эти интервалы произвольны и не имеют никакого отношения к SLA, заключённым на оцениваемые системы. Хотя в дальнейшем было бы правильно привязать типовые SLA именно к этим интервалам.

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

до 1 часа 1..4 часа 4..8 часов 8..24 часа
Экономические 1 1 3 3
Клиентские 1 2 2 3
Репутационные 0 0 1 2
Юридические 1 2 3 4

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

до 1 часа 1..4 часа 4..8 часов 8..24 часа
МАКСИМУМ 1 2 3 4

Шаг второй: по матрице транслируем полученные оценки в классы критичности:

Баллы до 1 часа 1..4 часа 4..8 часов 8..24 часа
4 MC MC BC BC
3 MC BC BC BO
2 BO BO BO OP
1 BO BO OP OP

Для данной системы получаем следующие оценки:

до 1 часа 1..4 часа 4..8 часов 8..24 часа
КЛАСС BO BO BC BC

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

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

Осталось несколько нюансов, без которых описанная методология была бы неполной.

Если система обеспечивает работоспособность другой системы, то её класс критичности не может быть ниже, чем класс зависимой системы. Например, Active Directory вообще никак не относится к бизнесу. Но если вдруг она встанет, то последствия для многих бизнес-приложений будут самые печальные, и поэтому AD однозначно относится к классу Mission critical.

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

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

Снабдите свои системы ярлыками и да будет ваша инфраструктура не менее надёжна, чем нужно, но и не дороже, чем можно!
Подробнее..

Управление проектом по Fix Time, Fix Budget, Flex Scope (FFF)

10.08.2020 12:13:56 | Автор: admin
Не мечта ли любого владельца компании управлять IT-продуктом так, чтобы поставлять продукт в срок, обгоняя конкурентов, и делать это с высоким качеством, радуя пользователей? Хотелось бы найти серебренную пулю для управления и, кажется, она есть. Не такая уж серебренная и не такая уж пуля, но довольно надежный и обкатанный годами подход к управлению, который можно назвать FFF: Fix Time and Budget, Flex Scope.

Почему и когда стоит выбрать FFF? Давайте посмотрим.

1. Три комбинации


Каждый из подходов к управлению проектом по сути отличается тем, что фиксирует или не фиксирует следующие величины: бюджет, объем работ, срок и внутреннее качество системы.


Конкретная комбинация создает определенные условия работы, имеет плюсы и минусы:

  1. Fixed price

    • Зафиксированы три точки проектного треугольника: срок, деньги и объем работы.
    • Основные риски берет на себя исполнитель и, как следствие, эти риски отражаются на оценке. Кроме этого создаются риски и для заказчика, об этом я писал в статье 12 проблем при работе по техническому заданию в IT-продукте.
    • Большим плюсом этого подхода является предопределенные до начала работ параметры проекта. Очень часто бизнесу/государству нужно прописать в договоре срок, деньги и объем работы.
    • Внутреннее качество при этом редко фиксируют. Зато почти всегда именно качеством жертвуют, чтобы в нашем изменчивом мире умудриться попасть в срок с фиксированным объемом работы. Почему так происходит и что является корнем проблемы, обсудим чуть дальше.
    • Оплата происходит в конце проекта с возможной предоплатой в начале.
  2. Time and Materials (T&M)

    • Зафиксированы деньги и внутреннее качество системы, хотя вторым частенько пренебрегают из-за халатности или неопытности с обеих сторон.
    • Заказчик берет в аренду ресурсы исполнителя по фиксированной ставке и управляет ими по своему усмотрению.
    • Исполнитель отвечает за то, чтобы дать максимально качественный продукт за счет своей компетенции.
    • Оплачивается при этом время, которое сотрудники исполнителя были заняты на проектах заказчика. Это происходит в конце отчетного периода, например, раз в месяц.
    • Основные риски берет на себя заказчик.
    • Если у заказчика есть четкое понимание задач и организован контроль работы (в том числе собственных ресурсов, особенно Product Owner'а), то это самый оптимальный и быстрый вариант управления, потому что он наименее бюрократизирован, соответственно, все занимаются только разработкой без лишних отвлечений на ритуалы согласований.
  3. Fix Time and Budget, Flex Scope (FFF)

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

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

2. Корень проблемы


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

Ни у кого не возникает проблем с расчетом бюджета, довольно легко посчитать дату релиза и есть множество метрик и чеклистов, чтобы задать конкретный уровень качества IT-продукта. Это всё просто, если вы можете точно оценить объем работ. Другими словами, если есть детальный список задач и точная оценка этого объема работ, то остальные три величины считаются легко. И наоборот, если точной оценки нет, то остальные величины тоже будут неточны, потому что основываются на оценке объема работ.

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

Подробнее об этой проблеме я писал в статье Customer satisfaction для программистов: Все программисты оптимисты. Там есть ссылка на доклад 36 от Вадима Макишвили, где он предлагает просто умножать оценку на 3. С помощью метафоры прокладывания и прохождения маршрута написано в статье Почему проекты в IT занимают в 2-3 раза дольше, чем планируется?.

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

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

Надо оговориться, что всё это справедливо, если вы работаете в достаточно сложной области: по Cynefin framework это области Complex и Complicated. Если же ваш проект попадает в Obvious и при этом он довольно короткий, то объем работы вы скорее всего оцените очень точно.

Итого, мы имеем, что корень проблемы в неточной оценке объема работ и практической невозможности сделать эту оценку точной, поэтому:

  • В Fixed price проектах жертвуют внутренним качеством системы, ведь попасть в оценку с тремя фиксированными вершинами почти невозможно. Либо в тех же Fixed price проектах перезакладывают в бюджет столько рисков, чтобы покрыть вообще любые неточности оценки, что является неэффективным.
  • В T&M легко уйти в неэффективное управление ресурсами, ведь постоянно отслеживать раздувание скоупа и обрезать его довольно сложно. Нужны правильные инструменты и очень сильные Product Owner'ы.
  • FFF заранее принимает, что объем работы не предсказать, но при этом забивает колышки на сроке и бюджете, чтобы избежать проблем T&M.

3. А может вообще не оценивать?


Если оценить объем работ нельзя с достаточной точной, то может вообще этим не заниматься? Есть такое движение #NoEstimates. Если коротко, то мы организуем процесс разработки так, чтобы максимально эффективно проводить задачи от этапа идеи до выкатки в прод и при этом сохранять высокое внутреннее качество. Организовывать процесс предлагают по Kanban с отслеживанием метрик обработки потока и особым вниманием к улучшению процесса доставки новых фич. Преждевременные оценки считаются вредными, оценка и грумминг бэклога потеря времени.

Где узнать больше о #NoEstimates:

  1. Об этом много рассказывает Дэвид Андерсон, например, в выступлении The Alternative Path to Enterprise Agility.
  2. Рассказывал Асхат Уразбаев на AgileDays в выступлении #NoEstimates: Безоценочная разработка.
  3. Писал об этом Рон Джеффрис в статье Some Thoughts on Estimation.
  4. На Хабре об этом писал Денис Стебунов в статье Об оценках сроков в разработке ПО.

Я двумя руками за этот подход. Он мне нравится, как инженеру и как руководителю. Но жизнь так устроена, что владельцам бюджета нужна оценка, хотя бы на первых этапах работы, хотя бы примерная. В Byndyusoft мы иногда переходим к #NoEstimates, но только после довольно длительных отношений с заказчиком и происходит это далеко не всегда.

4. FFF баланс гибкости и предсказуемости


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

Первый раз я увидел описание FFF в книге Getting Real от 37signals в главе Fix Time and Budget, Flex Scope. На данный момент в моей компании это самый популярный подход к работе, им довольны и заказчики, и мы.

5. Внутреннее качество системы


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

Почему не стоит забывать о внутреннем качестве, написано в блоге Мартина Фаулера в статье Is High Quality Software Worth the Cost?. Я писал об этом в статье Определение провала IT-проекта. Если сказать коротко, то при FFF предполагаются изменения в направлении развития продукта, а это подразумевает достаточную гибкость системы. Если качество системы низкое, то каждый поворот будет замедлять разработку и увеличивать ее стоимость, вплоть до полной остановки проекта.

Если вы хотите работать по FFF, то заложите критерии качества в контракт, чтобы зафиксировать их наверняка.

6. Мотивация заказчика и исполнителя


Работа по FFF дает правильную мотивацию со стороны заказчика и исполнителя. В отличие от Fixed Price, где заказчик и исполнитель общаются через интерфейс контракта, и в отличие от T&M, где заказчик может потерять границы и потратить больше, чем нужно; в FFF всем приходится вкладываться в коммуникации и жить в проекте, чтобы сделать самое важное и при этом удовлетворить условия контракта.

7. Выбираем FFF


Fixed price и T&M имеют свои преимущества в определенных контекстах:

  1. Если вы участвуете в тендере и обязуетесь выполнить конкретную работу за оговоренное время и деньги, при этом коммуникация по большей части выстроена через договор подряда, скорее всего, лучшим вариантом будет Fixed price.
  2. Если заказчик точно знает, что ему нужно, и умеет эффективно выстраивать процесс работы, то ему достаточно купить ресурсы по T&M и распоряжаться ими на свое усмотрение.

Тем не менее, при прочих равных мы стараемся выбирать FFF. Этот подход кажется наиболее сбалансированным: он снижает риски заказчика и исполнителя, создает нужную мотивацию с обеих сторон и заботится о внутреннем качестве системы.

Ссылки:

  1. Как и какое техническое задание писать при работе по Agile.
  2. Принцип управления проектами в дизайн-бюро Артёма Горбунова.
Подробнее..

Взлет и падение стартапа по аренде электровелосипедов Jump. Два года назад его за 200 млн купила Uber

28.07.2020 18:07:12 | Автор: admin


Photo: Bikeshare Museum

В 2018 году такси-сервис Uber купил стартап по аренде электросамокатов Jump за $200 млн. Однако всего спустя два года дела у проекта идут плохо. Создатель Jump и ключевые члены команды проекта покинули Uber еще в январе, а большинство сотрудников сократили, когда Uber продала Jump конкурентам из Lime. Вскоре после этого в интернете появилось видео огромного хранилища, на котором находятся тысячи никому больше не нужных красных электровелосипедов.

В нашей новой статье мы вспоминаем историю этого проекта и пытаемся разобраться в причинах падения стартапа на $200 млн.

История создания Jump


Вдохновившись истрией парижского сервиса аренды велосипедов Velib, Райан Ржепецки (Ryan Rzepecki) основал компанию Social Bicycles в 2010 году. Компания планировала предлагать городским администрациям закупать свои электровелосипеды и док-станции.

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

У компании была миссия сделать электротранспорт доступным для всех сотрудники верили в нее, но с технологиями не все получалось гладко. В первые годы жизни Social Bicycles постоянно сталкивалась с проблемами и претензиями со стороны заказчиков. Так в 2012 году компания заключила контракт на поставку электровелосипедов для аэропорта Сан-Франциско, но они так толком и не заработали.

Тем не менее, к 2016 году компания вышла на прибыльность, и поучаствовала в проекте Biketown его спонсором стала компания Nike, и в рамках инициативы в Портленде (штат Орегон) была размещена тысячи электровелосипедов.

Бурное развитие


Если первые годы проходили в упорной работе и постепенном продвижении вперед, то начиная с 2016 года ниша аренды велосипедов стала очень востребованной. Здесь появилось большое количество различных стартапов, в том числе китайский Mobike и американский Lime.

Инвесторы активно вкладывались в такие проекты, многие из которых использовали модель free lock, разрешая клиентам бросать велосипеды и самокаты прямо на улицах города. Вскоре во многих городах по тротуарам стало трудно передвигаться из-за брошенного электротранспорта. Стартапы Lime, Spin и Bird делали это в Сан-Франциско, что приводило к конфликтам с городскими властями.

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

Это было как в первый раз использовать iPhone просто магия, так характеризовал продукт один из топ-менеджеров Uber, который тестировал его перед покупкой стартапа.

В 2018 году Social Bicycles провела ребрендинг, взяв имя Jump. Вскоре состоялась и $200-миллионная сделка с Uber. Для компании это стало первым поглощением стартапа, который предоставлял в аренду какой-то другой вид транспорта, а не автомобиль. По задумке топ-менеджмента Uber, аренда самокатов и велосипедов для коротких поездок должна была помочь нарастить базу пользователей.

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

Когда начались проблемы


В мае 2019 года Uber провела IPO, которое стало крупнейшим к тому моменту. Начальная оценка компании составила $75,5 млрд.

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

Повлияла на проект и общая атмосфера внутри Uber. На момент поглощения Jump вокруг основателя такси-сервиса Трэвиса Каланика гремел один скандал за другим. Под сомнение ставились опыт, навыки и способность управлять коллективом многих руководителей.

В частности, подразделением Uber Mobility, в которое входил Jump, руководили люди без опыта работы в сегменте аренды электровелосипедов. В отличие от сегмента такси, это практически бизнес, построенный вокруг железа, но руководители этого не понимали. В их числе и руководитель Mobility Unit Рэйчел Холт, про которую бывшие сотрудники Jump говорили, что она понятия не имеет, как управлять hardware-компанией.

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

Зимой 2020 года журналисты выяснили, что Ржепецки и часть основной команды Jump покидают Uber. В начале мая появились и новости о том, что Uber будет один из основным участников инвестраунда стартапа по аренде электросамокатов Lime. Одним из условий сделки стало право Uber на покупку Lime в период с 2022 по 2024 год. Бизнес Jump теперь входит в состав Lime, а CEO компании стал Уэйн Тинг, много лет работавший топ-менеджером Uber.

В ходе реорганизации многих сотрудников Jump сократили на фоне пандемии коронавируса у Uber возникли финансовые трудности. Lime нужны только велосипеды, которые еще не были поставлены в города. Все остальные отправились на свалку.

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


Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Recovery mode Можно ли инвестировать в китайскую HUAWEI?

24.07.2020 22:13:05 | Автор: admin
Китайский технологический лидер обвиняется в политическом шпионаже, но он полон решимости сохранить и даже повысить свою прибыль на международном рынке.



Рен Чжэнфэй, бывший офицер Народно-освободительной армии Китая, основал компанию Huawei (произносится Wah-Way) в 1987 году. С тех пор китайская компания в Шэньчжэне стала крупнейшим в мире производителем смартфонов наряду с Apple и Samsung. Компания также производит бытовую электронику и строит коммуникационное оборудование и инфраструктуру. Она стала многонациональным гигантом с доходом в 1209 млрд долларов в 2019 году.

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

Где Huawei занимается бизнесом?


Кроме производства смартфонов, Huawei строит телекоммуникационные сети и оказывает сопровождающие услуги. По состоянию на 2019 год в компании работало более 190 000 человек в более чем 170 странах. Большая часть бизнеса находится в Китае, остальная в Европе, на Ближнем Востоке, в Африке и Азиатско-Тихоокеанском регионе.

Ключевые факторы


Huawei это многонациональная компания, производящая бытовую электронику и коммуникационное оборудование.

Несмотря на впечатляющий рост, компания на 100% принадлежит сотрудникам.
Huawei является предметом многочисленных споров, так как официальные лица США подозревают, что китайское правительство активно участвует в бизнес-процессах компании.
За исключением Америки, Huawei продолжает демонстрировать быстрый рост продаж во всем мире.

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

Где Huawei ведет свой бизнес и где его нет?


Глобальный скептицизм в отношении Huawei вырос в последние годы, когда в 2012 году Конгресс США выступил с докладом, в котором подчеркиваются риски безопасности при использовании оборудования компании. В то время как Huawei утверждает, что на 100% принадлежит сотрудникам, официальные лица США скептически относятся к тому, что китайское правительство и Коммунистическая партия могут влиять на нее. Закон Китая, обязывающий китайские компании оказывать помощь национальным разведывательным сетям, принятый в 2019 году, усилил эти опасения.

Санкции США против Huawei


14 месяцев назад США ввели санкции против Huawei, согласно которым компании больше не разрешается использовать американские технологии. Это санкции стали решающим фактором для Великобритании в объявлении запрета на продукцию китайского производителя. Великобритания больше не может быть уверена в том, что сможет гарантировать безопасность будущего оборудования Huawei 5G, затронутого изменением в правилах о прямых иностранных продуктах США, выразил свою обеспокоенность Оливер Дауден, министр цифровых технологий страны.

В январе 2018 года крупные американские мобильные компании AT & T и Verizon прекратили использовать продукты Huawei в своих сетях. В августе Австралия решила не использовать продукцию компании, поскольку она строит свои 5G-сети для всей страны. В ноябре Новая Зеландия запретила Spark, одной из крупнейших телекоммуникационных компаний страны, использовать продукты Huawei в своей 5G-сети. Несмотря на решения правительств этих стран, Huawei может вести бизнес с частными компаниями в каждой из них.

1 декабря 2018 года по требованию правительства США канадские чиновники арестовали Мэн Ваньчжоу, главного финансового директора Huawei и дочь основателя компании. 29 января 2019 года правительство США подало официальный запрос об ее экстрадиции, утверждая, что она нарушила санкции США против Ирана. США также запретили Huawei вести дела с американскими госкомпаниями из-за нарушений санкций.

В июне 2019 года президент Трамп снял ограничения на Huawei в рамках продолжающихся переговоров о торговле между США и Китаем. Тем не менее, Huawei объявила о планах сократить 600 рабочих мест в Санта-Кларе (штат Калифорния) и приняла решение перенести центр в Канаду к декабрю 2019 года.

Как Huawei зарабатывает деньги?


Huawei работает в сегментах перевозчиков, предприятий и потребителей. Поскольку компания не является публичной, она не торгуется ни на одном фондовом рынке и не обязана подавать заявки в Комиссию по ценным бумагам (SEC). Однако она по-прежнему регулярно сообщает о своих доходах.

В своем годовом отчете за 2018 год компания сообщила, что общий доход составил 107 миллиардов долларов США, что на 19,5% больше, чем годом ранее. Прибыль подскочила на 25%. Компания заявила, что продала более 200 миллионов смартфонов в 2018 году, что представляет собой впечатляющий рост по сравнению с 3 миллионами, проданными в 2010 году.
Huawei сообщил, что бизнес в Китае вырос на 19% в 2018 году, в Азиатско-Тихоокеанском регионе вырос на 15%, в EMEA (Europe, Middle East and Africa) вырос на 24,2%, а в Северной и Южной Америке упал на 7% и показывает снижение второй год подряд.

Почему нельзя инвестировать в Huawei?


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

В 2014 году высшее руководство Huawei спросили, будет ли оно рассматривать листинг на фондовом рынке, и ответ был отрицательным. Но со складывающимися вокруг компании обстоятельствами, вероятность выхода Huawei на публичный рынок существует, особенно если компании потребуется дополнительный капитал. Маловероятно, что Huawei выйдет на рынок США из-за плохих отношений и растущей репутации компании-шпиона.

Что касается инвестиций в Huawei, что называется здесь и сейчас есть только одно потенциальное решение, но оно аллегорично. Чтобы получать дивиденды, вам нужно стать сотрудником компании в Шэньчжэне (Китай), и заставить руководство поверить, что вы не шпион.

Успехов!
Подробнее..

Как выделиться с помощью сайта? Дизайн с ощущением левитации

23.07.2020 16:12:40 | Автор: admin

Процесс разработки сайта с анимацией


Современная платежная платформа это портал между бизнесом и потребителем в любой точке мира. Как показать это в дизайне?

image

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

Мы в BeaversBrothers решили поделиться практикой в создании сайта с персонажной анимацией для RBK.money. Расскажем о зарождении идеи с парящими персонажами, подходах, сложностях и решениях для веб-проектов.

Заказчик: RBK.money

Деятельность: платёжный агрегатор

Целевая аудитория: малый и средний бизнес

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

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

Мы презентовали основную идею дизайна сайта одновременно с согласованием его структуры. Это помогло нам сразу понять, что мы верно поняли задачу заказчика и видим проект одинаково.


Основой для будущего сайта стали яркие иллюстрации с сюжетом в стиле нового бренда с необычной анимацией, которая создаёт ощущение левитации.

1. Разработка сайта с погружением в бизнес-задачи заказчика


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

При выборе подрядчика компания ставит перед агентством два важных вопроса:

  1. Насколько результат будет соответствовать поставленным задачам?
  2. Успеет ли агентство выполнить работу в срок?

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

Именно поэтому работу начали с экспресс-аудита компании. Он помог нам понять продукт RBK.money и составить портрет целевой аудитории. Результатом аудита стал документ, в котором прописаны цели и задачи, описан продукт и ЦА. В нём мы предложили клиенту наше видение проекта и закрепили этапы работ. Прозрачность процессов помогла достичь взаимопонимания. Согласовали.

Как понять, когда и каким будет результат?


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

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

image

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

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

Наталья Сергиенко, директор по маркетингу RBK.money

2. Сделать удобный сайт для пользователей


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

Что помогает выстроить логику поведения пользователя на сайте?


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

Мы разделили целевую аудиторию на условные роли. В нашем случае их получилось три:

  • клиенты (подключение платёжной платформы),
  • партнёры,
  • персонал.

Мы составили подробные портреты и разобрали поведение каждого сегмента: какая им движет цель, на какой странице какое сообщение надо показать. Далее мы по блокам разработали прототипы каждой страницы сайта.

Создание Карты пользовательских сценариев один из самых значимых этапов разработки. Она позволяет навести порядок на страницах, разобраться с витиеватой структурой сайта, распределить контент и иллюстрации. Всё это ускоряет процесс разработки и в дальнейшем уменьшает количество правок. А готовый сайт делает удобным и понятным для пользователя.

Сложности и решения на этапе проектирования.


Первый экран сайта должен встречать пользователя правильно сформулированным и понятным УТП уникальным торговым предложением. Для платёжной системы привычное УТП это размер комиссии. Но в случае с предложением RBK.money оказалось, что вывести средний размер комиссии, которая зависит от оборотов компании, оказалось невозможным, поэтому заявленная минимальная цена будет вводить пользователя в заблуждение.

image

Решение нашлось в результатах Экспресс-аудита, который был проведён нами в начале проекта. Мы детально проанализировали критерии, по которым пользователь выбирает платёжный сервис. Один из основных удобство и скорость внедрения системы. Значит, акцент нужно делать на прогрессивности технологий, которые позволяют легко интегрировать платёжную систему в любой онлайн-бизнес. Нужно дать понять пользователю, что он не будет испытывать проблем с установкой решения RBK.money на свой сайт.

3. Дизайн может стать главной идеей сайта


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

Когда иллюстрации говорят о компании больше, чем текст

Акцент сайта мы предложили сделать на иллюстрациях с эффектом левитации. Такая идея взялась из инсайта: платёжная система портал между бизнесом и потребителем в любой точке мира.

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

image

Иллюстрации настолько удачно вписались в новый стиль компании, что команда RBK.money решила использовать персонажей не только на сайте. Мы передали файлы в исходниках.

image

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

Как анимация может заставить сайт летать


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

Сложности и решения по анимации сайта


Анимацию мы разработали в After Effects и экспортировали для веба с помощью плагина BodyMovin. Затем, мы использовали на странице lottie-web плеер, чтобы воспроизвести её на странице.

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



4. Разработка в четыре руки


Технические моменты разработки сайта

Разработка, вёрстка и тестирование проходили в обычном режиме. Финальной публикацией заказчик занимался самостоятельно.

На этот проект мы задействовали двух наших разработчиков, чтобы вести работу в 4 руки. Мы разделили между ними страницы, чтобы вёрстка шла параллельно. Это позволило одновременно провести для заказчика два релиза, что сократило сроки разработки страниц.

Мы оптимизировали вёрстку, чтобы добиться максимальной скорости загрузки страниц.

Приёмы и результаты по производительности страниц сайта RBK.money

Мы старались сделать сайт максимально быстрым, даже при плохом интернете.

В разработке мы ориентировались на два основных показателя:

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

В нашем случае получились следующие результаты:

  • Время загрузки первого контента 0,5 0,8 с
  • Время загрузки для взаимодействия 1,6 1,9 с

Общая скорость загрузки сайта 94 балла из 100 (инструмент Lighthouse).

Как мы работали с временем загрузки

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

Все изображения и иллюстрации векторные это уменьшает их размер и отображает без искажений на Retina-экранах.

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

Кроме того, нам было важно, чтобы согласованный дизайн идеально отображался на сайте и не требовал доработок.

Сложности и решения в вёрстке сайта

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

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

5. Результат разработки сайта


В назначенный день у команды RBK.money появился новый сайт. Получился отличный подарок к новому году для компании и её клиентов, ведь запуск произошёл в предновогоднюю неделю.

Наш веб-проект для RBK.money был отмечен международной наградой в области веб-дизайна Awwwards, 10 апреля после подведения итогов голосования на сайте премии мы получили специальный диплом. Также сайт RBK.money попал в подборку лучших примеров дизайна для веб-страниц от агрегатора Muzli от InVision: muz.li/inspiration/best-designed-landing-pages/.

Как сдать сайт в срок?

Чтобы сдать проект вовремя, мы работаем над процессами. Вот некоторые из тех, которые помогают нам в разработке сайта:

  1. Экспресс-аудит подготовительный этап, благодаря которому мы узнаём продукт и целевую аудиторию.
  2. Агрегация требований видим, что нужно сделать и каким будет результат.
  3. Карта пользовательских сценариев фиксируем, где и какую информацию ищет пользователь. Что нужно сделать, чтобы увеличить конверсию.
  4. Используем несколько разработчиков, которые трудятся в тесной связке в вёрстке. Процессы, которые можно вести параллельно нужно вести параллельно.
  5. Тестируем готовый проект в Pixel Perfect. Достигаем того результата, который был задуман.

Грабли проекта и мысли по их избежанию

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


image

P. S. Продолжение? Следует!

Работаем над личным кабинетом для RBK.money. Делаем его удобным и понятным.
Подробнее..

Recovery mode Как рассчитать стоимость работы компании?

30.07.2020 18:15:54 | Автор: admin
В контексте постоянно меняющихся условий баланс доходов и расходов не всегда легко просчитать. Во время пандемии многие IT-компании столкнулись с неплатежеспособностью клиентов и были вынуждены приостановить сотрудничество. Круг потенциальных клиентов стал более узким. При этом, зарплатные и кредитные обязательства остались. И в ситуации экстренной, и в ситуации повседневной бывает трудно отрегулировать денежный поток и правильно рассчитать стоимость нормочаса.

Наш финансовый директор Ольга Башкатова разработала Модель необходимого и достаточного объема продаж (МНДОП), которая помогает управлять изменениями в компании и заранее просчитывать экономические последствия.

Модель содержит в себе две ключевые точки: точку необходимого объема продаж (ТНОП) и точку достаточного объема продаж (ТДОП). Благодаря этому, мы понимаем, какой должна быть стоимость услуг компании и ежемесячная выручка, чтобы деятельность компании была безубыточной или приносила определенную прибыль (например, 20%).

Точка необходимого объема продаж рассчитывается по формуле: ТНОП = ОР(1 (П1НК+ П2 + П3 +...+ПN)), где ОР операционные расходы, включая фонд заработной платы (в денежном выражении);

П1, П2, П2, ПN значимые для компании варьируемые параметры, без учета желаемой прибыли (в доле от объема продаж);

НК налоговый коэффициент (необходим, если премии сотрудникам выплачиваются с валового дохода).

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

Точка достаточного объема продаж (ТДОП) учитывает необходимый уровень прибыли. Мы просто добавляем к варьируемым параметрам значение прибыли (например, 0,2, если это 20%).

image
На практике важны следствия из этих формул.

Стоимость нормочаса к продаже для ТНОП = ТНОПКВ
Стоимость нормочаса к продаже для ТДОП = ТДОПКВ, где
К это количество специалистов IT-отдела,
В ежемесячная выработка специалиста IT-отдела, час.

image
Для правильного проведения расчетов необходимо точно оценить операционные расходы компании. Есть расходы, объем которых примерно одинаков каждый месяц. Например, это аренда и содержание офиса, фонд заработной платы, реклама, лизинговые платежи, юридические услуги, амортизация. Такие расходы мы вносим в формулу в денежном выражении. А есть расходы, которые представляют собой процент от валового дохода (выручки). Например, это могут быть премии, налоги, риски. Мы оцениваем их, опираясь на опыт компании, актуальное законодательство и мнения экспертов.

Для наглядности сделаем расчет для студии Reactive:

ТНОП Reactive = (2 130 000 + 300 000)/(1 (0,07* НК + 0,06 + 0,01) = 3 300 000, где
2 130 000 фонд заработной платы со всеми налоговыми отчислениями (см. таблицу),
300 000 другие операционные расходы,
П1 премия команды (7% от валового дохода),
НК налоговый коэффициент (налоговые отчисления на премии),
П2 налог по УСНО/доход (6%),
П3 риски (технические трудности на крупных проектах 10% от валового дохода).

image
ТДОП Reactive = (2 130 000 + 300 000)/(1 (0,07* НК + 0,06 + 0,01 + 0,2) = 4 500 000.

Все то же самое, только добавляем в знаменатель желаемую прибыль в виде четвертого параметра (П4=20%).

Стоимость нормочаса к продаже для ТНОП Reactive = 3 300 000/16*100 = 2100
Стоимость нормочаса к продаже для ТДОП Reactive = 4 500 000/16*100 = 2900

Итак, при ежемесячном объеме продаж в 3,3 млн. доходы Reactive полностью покроют расходы. Прибыль компании будет равной 0. Стоимость нормочаса к продаже в этих условиях 2100.

При ежемесячном объеме продаж в 4,5 млн. прибыль компании составит 20% от валового дохода, стоимость нормочаса к продаже 2900.

image
Модель помогает решить несколько экономических задач:

1. Определить минимальный объем продаж такой, при котором компания останется на плаву и не будет нуждаться в заемных средствах.
2. Обеспечить равномерный ежемесячный приток денежных средств: корректируются формы и сроки выплат по контрактам.
3. Проанализировать финансовое состояние компании и уровень ее платежеспособности. Если уровень точки необходимого объема продаж пройден компания точно получит прибыль, если же эта точка не достигнута компания несет убытки. Чем сильнее доход компании превышает ТНОП, тем в большей степени она финансово устойчива.
4. Прогнозировать экономические последствия повышения зарплаты, расширения штата сотрудников, приобретения имущества, увеличения других видов расходов. Мы просто подставляем в формулы новые значения (новый уровень зарплаты) и видим, какой объем выручки нужен для таких изменений. Если текущие проекты, договоры обеспечивают такую выручку в необходимом временном диапазоне, то зарплату можно смело поднимать.
5. Определить стоимость нормочаса (часа работы компании) с помощью математических следствий из модели. Вносим в уравнение выработку технического отдела, количество IT-специалистов и видим в итоге стоимость нормочаса, необходимую для безубыточной работы компании.
6. Принимать верные решения о новых активах: покупать, арендовать или отказаться.

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

После внедрения в практику таких расчетов мы сбалансировали входящие денежные потоки по договорам, отказались от убыточных проектов. Стоимость услуг стала более понятной и прозрачной это порадовало заказчиков. Конечно, по-прежнему имеют место имиджевые проекты, которые дают возможность выйти на новый рынок, получить признание, претендовать на премию в сфере digital. Мы рассчитали новые плановые показатели для менеджеров, ориентированные на прибыль 20%. Экономически обосновали возможность покупать имущество в лизинг, расширять штат сотрудников и повышать зарплаты. В 2019 году наша компания смогла полностью отказаться от привлечения заемных средств, закрыть год с прибылью и индексировать заработные платы всех сотрудников.

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

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

Recovery mode TikTok взлетел неожиданно высоко, и у него есть все шансы получить гражданство США

03.08.2020 20:12:09 | Автор: admin
Поздно вечером 31 июля с борта Air Force One Трамп заявил журналистам: Что касается TikTok, то мы запрещаем его в США. Представитель Белого дома аргументировал решение тем, что Администрация серьезно обеспокоена вопросами национальной безопасности в отношении TikTok. Wall Street Journal следом сообщила, что ByteDance пытается пойти на значительные уступки Белому дому и планирует создание тысяч рабочих мест в течение трех лет. А агентство Reuters в эксклюзивной публикации, ссылаясь на двух людей, знакомых с этим вопросом, сообщает, что владелец TikTok не выдержал давления США и согласен уступить Microsoft весь бизнес в Соединенных Штатах.
Давайте разбираться, почему компания, стоимостью около 30 млрд долларов США, обвиняется в возможной передаче пользовательских данных коммунистической партии Китая





Основные даты развития TikTok:

Март-2012: основание компании Bytedance в Китае и запуск Neihan Duanzi приложения, которое помогает китайским пользователям делиться мемами
Сентябрь -2016: Bytedance запускает короткое видео приложение Douyin в Китае
Август -2017: Международная версия Douyin запускается под брендом TikTok в некоторых странах мира, но не в США
Ноябрь 2017: Bytedance покупает музыкальное приложение с синхронизацией с Musical.ly
Май 2018: по данным исследовательской компании Sensor Tower, TikTok становится самым загружаемым неигровым iOS-приложением в мире в первые три месяца года
Август 2018: Bytedance объявляет о полном закрытии Musical.ly и переводе пользователей на TikTok
Февраль 2019: TikTok оштрафован в США за обработку Musical.ly данных пользователей до 13 лет без родительского соглашения
Октябрь 2019: Марк Цукерберг из Facebook публично критикует TikTok, обвиняя его в цензуре
Ноябрь 2019: Cfius (Комитет по иностранным инвестициям США) начинает расследование TikTok по принципу национальной безопасности
Май 2020: TikTok нанимает бывшего руководителя Disney Кевина Мейера в качестве исполнительного директора подразделения и главного операционного директора Bytedance
Июль 2020 года: госсекретарь США Майк Помпео и президент Трамп заявили о возможном запрете TikTok
Август 2020: Microsoft подтверждает, что ведет переговоры о покупке и эксплуатации TikTok в США и на трех других рынках, добавив информацию об участии американских инвесторов в покупке части акций

Какие данные собирает TikTok?

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

Эти данные соотносимы с десятками других приложений, которые также имеют доступ до производимых операций миллионов своих пользователей. К примеру, Facebook со своими дочерними компаниями, Reddit, LinkedIn и др. сообщают о сборе аналогичных данных. Но некоторые позиции по сбору данных в TikTok все же вызывают у специалистов, мягко говоря, удивление. В их числе недавнее выявление того, что приложение регулярно читает буфер обмена пользователей копировать и вставить. Поэтому, управление по надзору за информацией в Великобритании не скрывает, что продолжает исследования над открытыми и скрытыми возможностями приложения.

На выпады ревнителей безопасности TikTok отвечает так:

Сто миллионов американцев пользуются TikTok для развлечения и связи.
Только в этом году мы приняли в нашу команду около 1000 человек из США и гордимся тем, что вскоре наймем еще 10 000 сотрудников.
Пользовательские данные TikTok в США хранятся в США под строгим контролем доступа сотрудников. Крупнейшие инвесторы TikTok могут быть из США.
Мы стремимся защищать конфиденциальность и безопасность наших пользователей, поскольку мы продолжаем работать над тем, чтобы приносить радость семьям и помогать строить карьеру простым обывателям на нашей платформе.

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



Переговоры Microsoft и TikTok

Покупка TikTok компанией Microsoft, которой принадлежит LinkedIn, даст американскому техническому гиганту гораздо большее присутствие в социальных сетях и, соответственно, конкурентные возможности.
Согласно Financial Times, некоторые руководители материнской компании TikTok ByteDance считают, что вмешательство Трампа является просто напросто переговорной уловкой, чтобы помочь Microsoft заключить более выгодную сделку.
TikTok отказывается комментировать возможную сделку с Microsoft, но уверенно заявляют о долгосрочном успехе TikTok. Но на родине Трампа находятся технические специалисты, общественные деятели, которые не согласны с политикой президента и просят осложнения между США и Катаем, основанные на торговых разногласиях и пандемии коронавируса, не переносить в сектор госбезопасности.
Так, бывший директор по безопасности Facebook, Алекс Стамос, в своем Твиттере задается вопросом, был ли шаг Трампа вызван проблемами национальной безопасности, и сам же на него отвечает: Это странно. Продажа на 100% TikTok американской компании считается радикальным решением и снимает все проблемы с защитой данных. Если Белый Дом даже добьется этого, мы знаем, что это не так.
Г-н Трамп также подвергся критике со стороны Американского союза гражданских свобод. Запрещение приложения, которое миллионы американцев используют для общения друг с другом, представляет собой угрозу свободе выражения мнений и технологически неосуществимо, сказала Дженнифер Грэник, консультант по надзору и кибербезопасности ACLU. Закрытие одной платформы, даже если это было бы юридически возможно, наносит ущерб свободе слова в Интернете и ничего не делает для решения проблемы неоправданного государственного надзора.
Microsoft подтвердила, что ведет переговоры с Bytedance о приобретении популярного приложения в США, Канаде, Австралии и Новой Зеландии и намерена завершить их к 15 сентябрю этого года. Некоторые интернет-провидцы уже предположили, что приложение может называться Microsoft Teens.

(Источник megatrends.su)
Подробнее..

Apple объявила о сплите акций что это такое и чем грозит инвесторам

12.08.2020 20:21:34 | Автор: admin


Компания из Купертино в конце июля 2020 года объявила о сплите акций. Этот шаг приведет к падению акций в цене. В нашей новой статье разбираемся в том, зачем это нужно Apple, и как повлияет на инвесторов в ее акции.

Что такое сплит акций, и зачем это Apple


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

В конце июля Apple объявила о сплите акций в пропорции 4:1. Компания из Купертино не будет выпускать новые акции, просто одна ценная бумага будет распадаться на несколько за каждую акцию инвесторы получат еще три. Стоимость бумаг при этом уменьшится, а количество акций в обращении вырастет в четыре раза. Капитализация компании останется неизменной, а значит цена акции упадет с примерно $400 до $100.

Именно отметка в $100 в США считается, что для инвесторов комфортной, а если акция сильно дорожает, это отпугивает многих из них. Сплит здесь способ вернуть акции в ценовой сегмент, интересный массовому инвестору. Также Apple входит в индекс Dow Jones, а средняя стоимость акций компаний в нем составляет примерно $130, прежняя цена бумаг Apple сильно выделялась на этом фоне.

Что все это значит для инвесторов


Процесс дробления акций будет осуществлен 24 августа к этому дню закончится регистрация акционеров, которые имеют право получить дополнительные акции. После этого число находящихся в обороте акций Apple увеличится с 12,6 млрд до 50,4 млрд.

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

Что касается дивидендов, то совет директоров Apple одобрил выплату $0,82 на акцию 13 августа это произойдет до сплита. Если же пропорцию сплита в будущем перенесут и на дивиденды, то выплаты на акцию окажутся вчетверо меньше немногим больше $0,2.

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

Не все компании используют сплит


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

Использование этого инструмента зависит от стратегии компании. Та же Amazon не использует сплит уже больше 20 лет. Противник этого метода и знаменитый инвестор Уоррен Баффет акции его холдинга Berkshire Hathaway с 80-х годов выросли до более чем $290 тысяч за штуку.

В России акции Apple и других американских компаний можно купить на Санкт-Петербургской бирже. Для этого не нужно открывать счет у иностранного брокера, достаточно будет российского счета. Открыть его можно онлайн.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Нескучные инвестиции для гиков

02.08.2020 16:06:23 | Автор: admin

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


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


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


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


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


К счастью, для этого не надо переступать через себя и заниматься всякой скукотой, можно делать это весело!




Дисклеймер. Статья из личного опыта автора: скомпилировано все прочитанное + опыт инвестиций. В опыт вошел коронавирусный кризис из которого автор вышел с увеличением портфеля в 2,5 раза. Это не учебник и нет никаких гарантий правильности выводов. Инвестиции чувствительная для всех нас область и мы должны принимать все решения полностью самостоятельно.


Манифест. Да-да, начнем с манифеста.


Цели манифеста


Должен вести к росту нашего портфеля на 100 и более % в год или, в случае неудачи, к росту на 5-10% в год на долгой перспективе.


Должен помогать жить радостно, избегать психологических перекосов.


Манифест гика-инвестора


  1. Инвестирование не самоцель и не главная работа. Это может быть прикольной игрой, но если нам нравится больше программировать, изучать мир и себя, то на это мы можем выделить ограниченное время. Например 2-3 часа по выходным. Или 15 минут каждый день. Whatever.
  2. Так как инвестирование касается чувствительных вопросов безопасности и базовых установок социального программирования, то любые удачи могут вести к раздуванию самомнения, а неудачи к нервам и самоуничижению. Поэтому мы заранее медитируем на две аксиомы:
    Никто не может предсказать рынок. Если мы рано продали или поздно купили, то это говорит о том, что у нас есть свое мнение и, что мы реализуем свое виденье. Все остальное побоку. Завидовать тем кто выиграл в лотерею или расстраиваться, что не выиграл заранее глупо.
  3. Свое ментальное состояние мы стабилизируем не только работой с умом, но и работой со стратегией. Мы не инвестируем больше 30% в рискованные активы ни при каких раскладах.
    Ежемесячно инвестируя 10% своего дохода мы не влияем на качество жизни, но создаем базовый оплот своего ментально-материального спокойствия и надежности.
  4. Мы не паримся про учет, экономию и т.п., мы просто безукоснительно выполняем пункт 3., а все остальное тратим на жизнь по собственному желанию.
  5. Мы инвестируем в реальный бизнес который нам нравится и который мы понимаем. Например, сравнивая nvidia и ibm я выберу nvidia. А boeing и ford даже не буду рассматривать. А кто-то поступит ровно наоборот.
  6. (рост 100% в год) Мы не читаем блоги и каналы разных аналитиков, мы читаем технические ресурсы и оцениваем будущее.
  7. (рост 100% в год) Мы не читаем экспертов ( или не верим им, или не расстраиваемся если поверили и надежды не оправдались). Мы смотрим технические каналы и читаем про свои штуки, которые нам и так нужны по стилю жизни. Мне интересно читать про новые процессоры и неинтересно про то, что происходит с золотом или нефтью. Я буду инвестировать в то, что мне интересно.
  8. (надежность) Семьдесят процентов мы инвестируем в акции, которые считаем по надежности выше, чем средний по мировым масштабам банк. Например, акции Apple надежнее сбербанка, дают примерно 2% годовых в долларах, растут примерно в 2 раза раз в 5-10 лет. Могут упасть на 10 лет, но потом скорее всего вырастут. Вероятность потери денег ниже, чем если держать их в любом российском банке или российкой недвижимости.
  9. (надежность) Мы не инвестируем в рублях.
  10. (надежность) Раз в неделю мы проверяем и обновляем страховки (стоп лоссы и т.п.). Это занимает 10 минут и дает нам гарантии безопасности на случай глобальных кризисов.

Практика


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


Итак, допустим я решил начать и у меня или есть Х денег + я хочу ежемесячно откладывать 10%.


Как мне реализовать манифест? Только самостоятельно, только следуя своим склонностям и изучая рынок. Для примера, я, как разработчик приложений и интересующийся в этой сфере новинками гик, приведу свой портфель и то как я выбирал брокера.


Практика выбор брокера


Для покупки продажи акций нужен брокер.


После работы с двумя российскими брокерами в течение года, я открыл счет в Interactive Brokers для покупки акции, которую в России невозможно купить, и изумился качеству приложения, скорости работы и комиссии, которая в моем случае, для выбранной акции, оказалась ниже на полтора порядка (да, в 15 раз).


Поэтому потихоньку я перевожу все активы к ним.


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


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


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


А если он современный и приложение хорошее, то вы сможете удобно и быстро совершать сделки.


Ну и маленькие комиссии позволяют не париться про количество сделок.


Практика портфель


По манифесту, портфель разбит на 2 части.


Надежная часть 70% (на 01.06.2020)


Надежная часть следует пункту манифеста 8. (с учетом всех остальных пунктов)


Мой портфель надежной части по манифесту.


Apple 50%
Nvidia 20%


Почему Apple?


  • Они платят примерно 2% годовых.
  • Я разработчик iOS и я знаю, что Apple выпустит новый процессор для маков. Я знаю, что маки де факто стандарт для разработчиков и с новыми процами их доля будет еще расти.
  • Я знаю что Apple скоро запустит девайсы дополненной и виртуальной реальностей.
  • Поэтому я ожидаю рост в 2-3 раза за 5-10 лет + ежегодно 2% по акциям.

Почему nVidia?


  • Они платят примерно 1% годовых.
  • Я на них майнил :)
  • Машинное обучение.
  • Видеокарты и игровая индустрия.
  • (узнал уже на дату написания статьи после покупки) Делают решения для автономного вождения. Заключили контракт с мерседесом.

Почему не Intel, AMD, IBM, Microsoft?


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


Вот оно веселье! Рискованная часть (на 01.06.2020)


Рискованная часть следует пункту манифеста 7. (с учетом всех остальных пунктов)


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


Пример 1, доход 250% за 3 месяца.


Как приходят гипотезы, которые приносят 250% дохода на относительно коротких промежутках времени?


Личный пример. В мае, читая обзоры про intel, я увидел, что они купили Moovit для усиления своей системы автономного вождения Mobileye (которую тоже купили несколько лет назад за 13 млрд).


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


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


Поэтому я купил Nio на значительную для себя сумму.


Результат на 01.08.2020 акция выросла более чем в 2,5 раза и при последующем падении отработала страховка и она продалась. То есть, вложив, например, в акцию 10 000 долларов я получил бы 25 000 по итогу.


График акций NIO


И вот в этом я вижу интересные инвестиции. Когда мы просто изучая интересные нам вещи, попутно можем создавать подобные гипотезы.


Будущее


Также у меня есть гипотеза 2, которая отработала частично (увеличение в 2 раза). Мое предположение рост в 5-10 раз. Но, также весьма вероятно обратное падение или даже ниже чем было. Но иначе быстрый рост капитала вряд ли возможен. Полное описание гипотезы в канале.


Плюс, я в ожидании гипотезы 3, которая должна появиться сама.


Что значит гипотеза появляется сама?


Для примера я сейчас начинаю программировать для виртуальной реальности и мне очень интересна эта тема. Вместо РФ зомбо-новостей, я читаю англоязычные технические ресурсы на эту тему. И, вполне вероятно, что гипотеза, как описанная выше с Nio, появится сама.


Итог


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


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


Спасибо что дочитали! Эта статья написана за несколько часов, не судите строго.


В телеграм канале я эпизодически буду писать новые гипотезы (если они появятся) и новые инсайты.


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

Подробнее..

Акселератор ВТБ стартапы учатся взлетать

13.08.2020 16:14:35 | Автор: admin
По статистике, выживает около 8 % стартапов, а успех приходит всего к 1 % из них. Главная причина неудачи нет спроса на товары или услуги: технология, может, и крутая, но потенциальные клиенты о ней не знают. Получается, чтобы не выстрелить вхолостую, надо ориентироваться на спрос с самого начала. Один из вариантов корпоративные акселераторы, которые создаются специально для поиска новых технологических решений, полезных компании-организатору.

По такому принципу уже третий год работает акселератор ВТБ, организованный при поддержке Фонда развития интернет-инициатив (ФРИИ). Мы помогаем запуститься стартапам, продукты которых изначально представляют для нас интерес, например могут увеличить прибыль или оптимизировать затраты. О том, как попасть к нам в акселератор и что может из этого выйти, рассказываем под катом.




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

Впрочем, стартаперы в любом случае не останутся внакладе: пилотный проект оплачивается, участники получают от 500 тыс. рублей, более глубокое понимание технологических потребностей банковской отрасли и бесценную экспертизу для дальнейшего развития продукта. Кроме того, стандартное для наших участников продвижение в СМИ и участие в мероприятиях работают на имидж начинающей компании: о новой технологии и её создателях узнают другие потенциальные клиенты, так что для стартапа почти всегда возможны альтернативы.

Кроме того, у нашего партнёра ФРИИ есть приличный опыт в сфере развития технологических стартапов свыше 470 инвестиционных сделок на разных стадиях с IT-компаниями, большая база контактов и отработанная программа акселерации. Участники акселератора получают советы экспертов, доступ к базе потенциальных клиентов, помощь в отладке организационных и бизнес-процессов и многое другое. Стартап в итоге понимает, что делать и в каком направлении двигаться, чтобы получить клиентов.

С 2018 года мы запустили 32 пилотных проекта, 20 из которых успешно завершены. Не менее 10 решений находятся на различных стадиях внедрения в промышленную эксплуатацию. Получается, что выживаемость стартапов, участвующих в нашем акселераторе, примерно в 4 раза выше среднестатистических 8 %. И это вполне объяснимо: начнём с того, что стартап представляет своё решение большому количеству подразделений банка, а значит, имеет высокие шансы найти правильного заказчика. ВТБ крупнейший банк с 1,6 тыс. розничных отделений в РФ, так что после успешного пилота у стартапа есть все возможности для выхода на федеральный уровень.

Как это было


В 2019 году на участие в акселераторе была подана 581 заявка. Условиям отбора соответствовал 301 стартап, из них мы выбрали 12 самых перспективных: сервисы для розничных клиентов и малого бизнеса, инструменты b2c-маркетинга, решения для контакт-центров, технологии оценки потенциальных заёмщиков, инструменты сбора и анализа данных и другие решения:

  • Andata: цифровой паспорт клиента технология для идентификации потенциального клиента на сайте.
  • HintEd конструктор для создания интерактивных подсказок для пользователей корпоративных систем.
  • SweetCard.Stories платформа персональных Stories в мобильном банке с использованием Machine Learning.
  • MobileScoring сервис оценки заёмщиков на основе анонимизированных поведенческих данных клиентов, агрегированных по банкам-партнёрам.
  • OpenTRM автоматическое извлечение данных из сканов первичных документов.
  • KVINT платформа по созданию виртуальных голосовых операторов.
  • Neurodata Lab решение для Customer Experience Management на основе эмоционального искусственного интеллекта.
  • Botman.one визуальный конструктор, позволяющий создавать веб-приложения без помощи программистов.
  • HighTouch Lab удалённая верификация пользователей мобильных сервисов.
  • ТурбоКонтракт конструктор документов с возможностью работы множества пользователей.
  • Cyberatonica Platform платформа транзакционного фрод-мониторинга и адаптивной аутентификации пользователей.
  • WeHire оценка кандидатов с помощью игровых тестирований и эмоционального искусственного интеллекта.

Акселератор глазами участников


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

Артем Таганов, СЕО HintEd:

Наш интерес к акселератору можно описать тремя пунктами:
  • привлекала идея быстрого запуска пилотирования технологии;
  • мы понимали, что сотрудничество с ВТБ поможет в развитии;
  • хотелось отработать технологию на новых системах и платформах.

Через несколько дней после того, как мы подали заявку на сайте акселератора, с нами связался представитель ФРИИ. Мы пообщались по Skype, рассказали, что из себя представляем, какие у нас есть наработки. После этого прошли экспертную сессию с разными подразделениями ВТБ. Такой 3-часовой speed-dating: несколько десятков столиков с представителем отдельного подразделения банка за каждым из них. Мы рассказывали, что можем предложить, а представители банка решали, нужна ли им эта технология. Следующий этап Demo Day. Это был питч продолжительностью 3 минуты, мы рассказывали о своём проекте высшему руководству банка. Ну и финальный этап отбор в акселератор.
В своём проекте мы предложили заменить традиционное обучение сотрудников как очное, так и по инструкциям или видео, интерактивным форматом. Он совместим с системами, с которыми работают пользователи. А в банке как раз внедрялось несколько новых систем, так что для обучения работе с ними нужно было подготовить сотрудников.
Нашу технологию, которая помогает обучаться быстро и без отрыва от работы, протестировали корпоративное подразделение банка, департамент малого и среднего бизнеса, а также розничное подразделение. Тестирование прошло отлично, планируем сделать HintEd общебанковской системой.

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

Василий Кузнецов, СЕО SweetCard:

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

На мой взгляд, решающим этапом стал speed-dating именно там решалось, кого пропустить дальше, к выступлению перед жюри. Хочу отметить поддержку ФРИИ: представители фонда не только помогали участникам подготовить выступления, но и содействовали тому, чтобы все презентации были услышаны.
На акселератор мы пришли с платформой для встраивания в мобильное приложение банка ленты персональных Stories, которую можно настроить с учётом интересов и трат конкретного клиента. В результате мы запустили с ВТБ проект персональных анимированных итогов 2019 года.
Клиенты получили детальный персональный отчёт о тратах в различных категориях и зарубежных поездках. Иногда такой отчёт становится большим сюрпризом для человека, который не особо контролирует свои траты. Это реальная забота о клиентах: банк становится ближе к своим пользователям. Нашим главным заказчиком стало CRM-подразделение банка. В планах внедрение в банке полного функционала платформы.

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

Акселератор-2020: не пропустите третий набор


Несмотря на пандемию и связанные с ней сложности, мы открываем третий набор технологических компаний в корпоративный акселератор ВТБ и ФРИИ. Заявки принимаются до 24 августа включительно. Нам нужны:

  • Инструменты маркетинга
  • Сервисы для работы с клиентами
  • Сервисы для b2с-клиентов
  • Сервисы для b2b-клиентов
  • Решения в области HR
  • Сервисы для сотрудников
  • Решения для сбора и анализа данных клиентов
  • Решения в области кибербезопасности

Вполне может быть, что мы ждём именно ваш продукт. Главное соответствовать условиям:

  • Понятное ценностное предложение
  • Готовый к тестированию продукт
  • Готовность доработать продукт под наши требования
  • Юрлицо или ИП в России или за рубежом

Этапы акселератора:

  • До 24.08 приём заявок.
  • С 25.08 по 18.09 заочный отбор проектов экспертами ВТБ и ФРИИ.
  • До 01.10 отборочный интенсив.
  • С 05.10 подготовка к пилотированию и реализации пилота.

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

Разбор почему акции AMD выросли почти на 2000 за пять лет, и каковы их перспективы

21.07.2020 20:05:11 | Автор: admin


В январе 2015 года за одну акцию производителя процессоров AMD давали $2,69. В июле 2020 ценные бумаги подорожали до $55,04 за штуку рост за пять лет составил почти 2000%. Что помогло компании переломить неудачный тренд и вернуть утерянные позиции на рынке, а также что будет с ее акциями дальше? Разбираемся в нашей новой статье.

Немного истории


Компания AMD (Advanced Micro Devices) появилась еще в 1969 году. Сегодня она производит центральные и графические процессоры для ПК и серверов. Помимо этого, компания вовлечена в проекты в сферах машинного обучения, искусственного интеллекта и блокчейна.

При этом уже более 10 лет компания сама не занимается производством, а размещает заказы на мощностях других компаний. Такой бизнес-модели нет ни у кого из основных конкурентов, среди которых Nvidia, Intel и другие.

Десять лет назад доля AMD на рынке серверных чипов доходила до 20%. Однако компания не смогла вовремя выпустить новое поколение микросхем и проиграла конкуренцию Intel. В итоге за несколько лет доля рынка Advanced Micro Devices снизилась до 1%.

Как AMD переломила ситуацию


Ситуация начала меняться со сменой гендиректора компании. В октябре 2014 года этот пост заняла Лиза Су. При ней компания смогла освоить 7-нанометрового технического процесса и запустила линейку 7 нм серверных чипов. Это стало настоящим прорывом на момент появления таких процессоров у AMD в intel выпускали еще 14-нанометровые чипы и только планировали переход к 10 нм.

Помимо этого, AMD удалось удешевить производство, в результате чего ее продукция оказалась дешевле чипов конкурентов. Это позволило привлечь крупных заказчиков, в число которых вошли Amazon, Google и Microsoft.

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

В итоге к 2019 году доля AMD на рынке серверных чипов составляла уже 8%, а согласно прогнозам, в 2020 году должна составить 10%.

Перспективы


На данный момент AMD продолжает активно развиваться и выпускать на рынок новые продукты. Так, в июне 2020 года AMD выпустила обновленную серию процессоров Ryzen третьего поколения для ПК. Кроме того, до конца года ожидается выход на рынок ЦП Ryzen серии 4000, построенных на новой архитектуре Zen 3.

Растут и финансовые показатели компании. В первом квартале 2020 выручка AMD превысила доходы за аналогичный период прошлого года на 40% и составила $1,79 млрд. Этот результат превзошел ожидания экспертов. Также в 10 раз увеличилась чистая прибыль рост до $162 млн.

При этом, существуют и моменты, ограничивающие рост акций AMD:

  • Компания не платит дивиденды главные конкуренты из Intel раз в четыре года их выплачивают (доходность 2,3%).
  • Есть признаки переоцененности акций AMD многие аналитики убеждены, что ценные бумаги компании сегодня стоят даже дороже, чем должны, исходя из бизнес-показателей.
  • Маржинальность хуже, чем у конкурентов. В первом квартале валовая маржа AMD составил 46% (сколько денег от общей выручки осталось после вычета себестоимости производства). Показатель Intel превышает 60%.

Это не мешает руководству компании, аналитикам и инвесторам ждать дальнейшего роста. Так по прогнозам, во втором квартале 2020 продажи составят $1,85 млрд, что на 21% больше чем в аналогичный период прошлого года. А рост квартал к кварталу составит 4%.

В России акции американских компаний, включая AMD и их конкурентов из Intel, можно купить на Санкт-Петербургской бирже. Для этого не нужно открывать счет у иностранного брокера, достаточно будет российского счета. Открыть его можно онлайн.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Открыт прием заявок на соискание грантов от RIPE NCC

27.07.2020 00:14:29 | Автор: admin
Фонд общественных проектов (Community Projects Fund) RIPE NCC ежегодно оказывает финансовую поддержку инициатив, имеющих значение для работы и устойчивости Интернета. Как и в прошлые годы, в 2020 году организация выделяет на эти цели 250 000 евро. Гранты Фонда распределяются среди нескольких лучших проектов.



Принять участие в отборочном туре может как компания, так и отдельный специалист самостоятельно. Главное, чтобы участник продемонстрировал, как именно его проект будет полезен, и на какую сумму поддержки он рассчитывает. Количество заявок от каждого участника не ограничено. Все заявки проходят первоначальное утверждение к участию, а затем поступают на оценку международного отборочного комитета. В его состав входят пять членов сообщества RIPE и член правления RIPE NCC: Jaya Baloo, Nuno Garcia, Bert Hubert, Andreas Larsen, Tim Wattenberg и Remco van Mook. Уровень финансирования единичного проекта не регламентируется, а выделенная на гранты сумма распределяется по всем проектам-победителям в соответствии с заявками.

Впервые идею поддержки общественных инициатив пользы Интернета обсудили в ходе общего собрания RIPE NCC в ноябре 2014 года, а в 2017 году первые участники получили финансовую поддержку для реализации своих проектов. Опыт показал, что за относительно короткий период приема заявок о своих идеях и начинаниях успевают заявить активисты из трех десятков стран, а число заявок приближается к ста. В 2019 году было выбрано 7 победителей, четыре из которых были посвящены информационной безопасности (Antikraak, ARTEMIS, ASNR, Cryptofuzz), два мониторингу (IRRexplorer v2, Мониторинг здоровья экосистем RPKI) и один внедрению IPv6 (улучшение поддержки IPv6 в сетях Tor). Познакомиться с проектами-победителями прошлых лет можно в архиве.

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

Инвестируй как Гейтс в какие акции вкладывается фонд основателя Microsoft

14.08.2020 18:11:43 | Автор: admin


By Kjetil Ree Own work, CC BY-SA 3.0

Основатель Microsoft уже давно отошел от управления бизнесом и оставил себе лишь 1,36% акций компании. Последние годы Гейтс, чье состояние составляет примерно $113 млрд (второй богатейший человек в мире), больше вовлечен в благотворительность. Совместно со своей женой еще в 2000 году он основал фонд Bill & Melinda Gates Foundation, который финансирует такие проекты его объем превышает $45 млрд.

Помимо этого, у фонда есть траст, который используется для инвестиций фонд не только тратит деньги. Согласно данным отчета, который был подан в Комиссию по ценным бумагам и биржам США (SEC), инвестпортфель фонда в первом квартале 2020 года составил $17,35 млрд.

В какие же акции инвестирует фонд основателя Microsoft? Изучаем в нашей новой статье.

1. Berkshire Hathaway


Это крупнейший актив в портфеле фонда (47,3% от оценки всего портфеля). Berkshire Hathaway это инвесткомпания Уоррена Баффета, который считает одним из самых успешных финансистов в истории. Холдинг владеет долями в таких компаниях как Apple, Coca-Cola, American Express.

2. Waste Management


Это крупнейшая в США компания по сбору, транспортировке и переработке твердых отходов. Впервые в портфеле Билла и Мелинды Гейтс акции компании появились в 2002 году. Сегодня фонд владеет более чем 18,6 млн акций Waste Management.

3. Canadian National Railway


Доля этого актива в портфеле фонда Гейтса составляет 7,66%. Canadian National Railway крупнейшая в Северной Америке железнодорожная сеть. Сейчас фонд Гейтсов владеет 17,13 млн ее акций.

4. Walmart


Крупнейшая в мире розничная сеть, супермаркеты Walmart настоящий символ США. Компания владеет более чем 10 тысячами магазинов, многие из которых находятся в Америке глобальная сеть покрывает 27 стран. В портфеле Гейтсов доля акций Walmart составляет 7,6%.

5. Caterpillar


Ведущий мировой производитель строительной, транспортной техники и энергетического оборудования. Фонд Гейтсов вкладывается в ценные бумаги Caterpillar на протяжение 15 лет, и сейчас в нем накоплено 11,26 млн акций компании.

6. Crown Castle International


В свою очередь, эта компания крупнейший в США поставщик оборудования для беспроводной связи. В портфеле Bill & Melinda Foundation находится 5,33 млн ее акций.

7. Ecolab


Поставщик моющих и дезинфицирующих средств, продукция которого используется главным образом на предприятиях общепита, в гостиничном бизнесе, здравоохранении, розничной торговли и образовательных учреждениях. В последние месяцы стоимость ценных бумаг Ecolab росла, сейчас фонд Гейтсов владеет 4,36 млн акций.

8. United Parcel Service


UPS одна из крупнейших в мире компаний, занимающихся экспресс-доставкой документов и посылок. В портфеле Гейтсов доля этого актива составляет 2,44%, что равняется примерно 4,5 млн акций.

9. FedEx


Еще один бизнес в сфере логистики. Как и UPS, FedEx доставляет грузы и корреспонденцию по всему миру.

10. Schrodinger


Эта компания занимается разработкой сложного софта, который помогает в создании новых лекарств. Выход Schrodinger на биржу состоялся лишь в феврале 2020 года. Почти сразу же фонд Гейтсов приобрел 7 млн ее акций, что превысило 11% от их общего числа.

В России акции Walmart и других американских компаний можно купить на Санкт-Петербургской бирже. Для этого не нужно открывать счет у иностранного брокера, достаточно будет российского счета. Открыть его можно онлайн.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Перевод Как работали кредиты в Древнем Риме

30.07.2020 14:08:36 | Автор: admin

Представьте, что вы житель Древнего Рима в первом веке до нашей эры. Ваша жена убеждает вас купить определённый предмет. Он довольно дорогой, поэтому вы колеблетесь, ведь наличных у вас маловато. Можно было бы представить, что подобное оправдание в те времена позволило бы вам остаться безнаказанным. Ведь какой у вас выбор: нельзя же выписать чек? Вообще-то можно, как пишет поэт Овидий в книге первой "Науки любви". И так как ваша жена об этом знает, другого выхода у вас нет:

Женщина средство найдёт страстных мужчин обобрать.
Вот разносчик пришел, разложил перед нею товары,
Их пересмотрит она и повернётся к тебе,
Выбери, скажет, на вкус, посмотрю я, каков ты разборчив,
И поцелует потом, и проворкует: Купи!
Скажет, что этого ей довольно на долгие годы, Нужную вещь продают, как же ее не купить?
Ежели денег, мол, нет при себе попросит расписку,
И позавидуешь ты тем, кто писать не учен.

(Перевод М. Л. Гаспарова.)

Во времена Рима крупные суммы денег меняли хозяев. Люди покупали недвижимость, торговали и инвестировали в провинции, захваченные римскими легионами. Как же это происходило? В своих Письмах Fam., V, 6 и Письмах Att., XIII, 31 Цицерон пишет: Я купил за 3500000 сестерциев тот самый дом через некоторое время после твоего поздравления и ближайший сосед Гай Альбаний; он купил тысячу югеров [625 акров] у Марка Пилия, насколько я помню, за 11500000 сестерциев. Как?, задаётся вопросом историк Харрис (в своей книге "The Nature of Roman Money"), Как Цицерон заплатил три с половиной миллиона сестерциев, которые он выложил за свой знаменитый дом на Палатине Для этого бы понадобилось погрузить и переместить три с половиной тонны монет по улицам Рима. Когда Гай Альбаний купил имение у Марка Пилия за одиннадцать с половиной миллионов сестерциев, он физически отправил ему эту сумму в серебряных монетах? Харрис отвечает на это так: Почти без малейших сомнений, по крайней мере бОльшая часть суммы передавалась через документальные [т.е. бумажные] транзакции. Самая популярная процедура покупки крупной собственности в тот период упоминается Цицероном [Об обязанностях. Книга II, 3.59] nomina facit, negotium conficit предоставление кредита [или обязательства nomina] завершает покупку.


Марк Туллий Цицерон

Что же такое эти nomina, от которых, между прочим, произошло понятие номинальный, обычно используемое в экономике? В своей диссертации на степень Ph.D. "Bankers, Moneylenders, and Interest Rates in the Roman Republic" Чарльз Барлоу пишет (стр. 156-156): Запись в счётной книге назывался nomen. Изначально слово обозначало именно это имя с какими-то числами. Ко времени Цицерона [n]omen могло также обозначать долг, относящийся к записям в счётных книгах кредитора и должника. И этот долг на самом деле был кровью экономики Рима на всех уровнях nomina были совершенно стандартной частью жизней владеющих собственностью, а также повседневным фактом для большого количества прочих людей (Харрис, стр. 184). Плиний Младший, например, писал (в Письмах): Возможно, ты спросишь, смогу ли я без трудов получить эти три миллиона. Почти весь мой капитал вложен в землю, но у меня есть деньги, вложенные под процент, и я могу позаимствовать тебе их без затруднений.


Реконструкция зданий на холме Палатин

Ради конкретности представим, что некий друг Семпроний должен вам один миллион сестерциев. Вы сами, или в случае, если вы богатый сенатор или эквит, то ваш финансовый советник (прокуратор для Цицерона это был Тит Помпоний Аттик) запишет долг в книгу учёта. Что если вам понадобятся деньги на покупку какой-то собственности? Вам придётся ждать, пока Семпроний принесёт вам мешок с миллионом сестерциев? Нет! Так как Семпроний надёжный кредитор (bonum nomen [см. Барлоу, стр. 156]; в современной терминологии агентств кредитной классификации AAA-кредитор), вы сделаете так, как описал Цицерон: передадите nomina и заключите сделку. Например, Цицерон пишет своему финансовому советнику Аттику (Письма Att., XII, 31): Если бы я продал обязательство Фаберия, я не поколебался бы приготовить даже наличные деньги для Силиевых, если бы только удалось склонить его к продаже. Харрис (стр. 192) замечает: Nomina были обращаемыми и ко второму веку до нашей эры, если не раньше, привычно использовались как средство оплаты других активов На латыни процедура, по которой плательщик передаёт nomen того, что ему должны, продавцу, называется delegatio.

Итак, мы поняли, что римляне могли проводить расчёты передачей nomina. Но существовал ли рынок для nomina, как в современном мире существуют, например, ценные бумаги с ипотечным покрытием? По мнению и Барлоу, и Харриса, можно дать положительный ответ. Они утверждают, что римляне сделали ещё один шаг в сторону обращаемости и, по сути, превратили простые записи из счётных книг в оборотные вексели (см. Барлоу, стр. 159, и Харрис, стр. 192). С этим согласны не все. Экономический историк П. Темин ("Financial Intermediation in the Early Roman Empire") тоже сообщает о наличии свидетельств возможности переуступки долгов, открывающей возможности более широкой обращаемости. Но, добавляет он, у нас нет никаких свидетельств того, что это происходило (стр. 721). Тем не менее, косвенные доказательства есть. Например, смысл оборотных векселей, похоже, был хорошо понятен римским юристам, в частности, Ульпиану (Дигест Юстиниана XXX.I.44): Сторона, передающая вексель, передаёт долговое требование, а не только материал, на котором оно записано. Фактом продажи подтверждается, что при продаже векселя продаётся и задолженность, которой она подтверждается.

А что если нам нужно перевести деньги кому-то в другой части мира? Когда доминионы
Рима расширились до Греции, Испании, Северной Африки и Азии, финансы Рима столкнулись с этой логистической проблемой. Если вы находитесь в Риме и, допустим, хотите профинансировать шахты Гая в североафриканском Тапсе, то как передать ему деньги? Ему нужно серебро для покупки материалов, рабов и других товаров, но вы, естественно, очень не хотите отправлять деньги в Африку морем их шансы добраться туда невысоки (им угрожают пираты, кораблекрушения и т.д.). Замечательным вкладом Рима в банковское дело античности стала permutatio передача средств при помощи бумажных транзакций (Барлоу, стр. 168). Она работала следующим образом: публиканы были частными компаниями, занимавшимися сбором налогов в провинциях (а также многими другими делами; см. статью "Publicani" Ульрика Малмендиера). У них существовал филиал в Риме и ещё один в Тапсе. Поэтому если вы давали им серебро в Риме (или передавали им nomina), то часть собранных в Северной Африке налогов они направляли Гаю. Точно таким же образом Республика финансировала свои государственные расходы на внешних территориях. Так как налоги собирались во всех провинциях, обменивая долговые обязательства на налоги, римляне могли переводить средства по всему миру или, по крайней мере, по той его части, которую захватил Древний Рим.


Рим в 40 году до нашей эры

Любопытно, что некоторые историки измеряют развитость финансовой системы Рима по степени присутствия банков (Темин, стр. 719). Разумеется, если мы не найдём в первом веке до нашей эры свидетельств существования нашего банка, то это не обязательно подразумевает отсутствие развитости. До Великой рецессии в США [финансового спада 2007-2009 годов] большая часть финансового посредничества не задействовала банки оно происходило через "теневую банковскую систему". Финансовая аристократия Рима действовала в основном при помощи брокерства (К. Вербовен "Faeneratores, Negotiatores and Financial Intermediation in the Roman World", стр. 12), а потому немного напоминала предшественника теневой банковской системы. Как и теневая банковская система США, она была хрупкой. Вернёмся к нашему первому примеру: стоит заметить, что если тот, кто желает приобрести собственность, начнёт сомневаться в кредитоспособности Семпрония, то не примет его платёж в nomina и потребует наличных. Это заставит вас потребовать возврата долга у Семпрония, которому в свою очередь придётся требовать возврата долга у Тита, и так далее. Однако финансовые кризисы Древнего Рима это тема для отдельной статьи.

Мы выражаем благодарность Кэмерону Хокинсу из Чикагского университета за помощь в поиске литературы.
Подробнее..

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

25.07.2020 18:20:04 | Автор: admin


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

О какой проблеме идет речь


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

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

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

Что может пойти не так


Хемптон объясняет проблему на примере:

Допустим, существует два золотых рудника. Капитализация каждого из них примерно $250 млн, и считается, что запасы золота в каждом составляет примерно 1 млн унций. Извлечь его планируется в период с 2024 по 2037 год.

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

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

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

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

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

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

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

Как противостоять подобным ситуациям


По мнению Джона Хемптона, существует два способа противостоять подобным ситуациям. Первый и доступный частным биржевым торговцам не вкладывать в спекуляции с короткими продажами значительные средства, выделять 0,1% капитала.

Второй больше подходит компаниям и фондам, которые могут пойти по пути знаменитого американского спекулянта Карсона Блока. Он профессионально занимается игрой на понижение и для этого основал исследовательскую компанию Muddy Waters Research, которая специализируется на поиске нарушений и проблем в бизнесе китайских компаний, акции которых торгуются на бирже.

Фонды могут сами заниматься таким анализом или прибегать к услугам компаний, вроде Muddy Waters Research. И даже в этом случае им остается надеяться на то, что им удастся сбить цену акций явно переоцененной компани на 30-40%, а также подготовиться к возможным последствиям шорта на 5% если стратегия не сработает сразу.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Почему произошел крах платежного стартапа Wirecard, и как это повлияло на сферу финансов

02.08.2020 16:06:23 | Автор: admin


Немецкий финтех-сервис Wirecard в последние годы стал одним из крупнейших в Европе поставщиков финансовых услуг. Компания выпускала физические и виртуальные карты, осуществляла процессинг онлайн и мобильных платежей. Wirecard купил собственный банк, капитализация сервиса составила 24 млрд больше чем Deutsche Bank и со временем его акции даже вошли в немецкий биржевой индекс DAX.

Все закончилось в июне 2020 года. Регуляторы и аудиторы из Ernst & Young приши к выводу о том, что компания много лет манипулировала с отчетностью, завышала показатели бизнеса, привлекала кредиты и потеряла на своих счетах 1,9 млрд. Позднее выяснилось, что эти деньги скорее всего никогда не существовали в реальности.

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

Как развивался скандал


Зимой 2019 года журналисты издания Financial Times опубликовали расследование о деятельности азиатского подразделения Wirecard. Издание заявило, что финтех-сервис специально завышал выручку в своей отчетности, осуществлял поддельные сделки и проводил денежные переводы через дочерние компании.

Тогда Wirecard отрицала все обвинения и даже подала в суд на FT руководство компании обвинило журналистов в сговоре с инвесторами, играющими на понижение стоимости акций. Компанию поддержал даже немецкий финансовый регулятор BaFin, который открыл дело о возможном манипулировании рынком и на два месяца запретил короткие продажи акций Wirecard.

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

Но журналисты FT не остановились и продолжали расследовать деятельность Wirecard. В итоге им удалось выяснить целый ряд шокирующих факторов:

  • Компания на протяжение 10 лет обманывала аудиторов из Ernst & Young.
  • Махинации с отчетностью осуществлялись в офисах по всему миру, включая подразделения в Дублине и Дубае.
  • Аналогично, практика фиктивных сделок, которые проводились через дочерние компании и записывались в качестве прибыли, оказалось для Wirecard глобальной.

Компания снова не согласилась с обвинениями и наняла независимого аудитора KPMG. Однако эта компания также не смогла подтвердить сделки за 2016-2018, на которые пришлась значительная доля выручки Wirecard. Сервис не смог собрать достаточно документов для опровержения фактов, изложенных в журналистских расследованиях. Последним гвоздем в крышку гроба Wirecard стало сообщение Ernst & Young о том, что аудиторам не удалось подтвердить наличие 1,9 млрд на счетах компании.

Вскоре гендиректор компании Маркус Браун подал в отставку, затем его арестовали и выпустили под залог, а акции Wirecard упали до отметки в 1-2.



Как крах Wirecard повлиял на сферу финансов


На момент банкротства Wirecard сотрудничала с сотнями тысяч компаний по всему миру, среди которых и крупные проекты. В их числе: Revolut, Tencent (WeChat Pay), Payoneer, Rakuten, Apple, Visa, MasterCard, China UnionPay.

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

  • Curve
  • Pockit
  • U Account
  • McLear Ring
  • Crypto.com cards
  • Anna Money
  • CardOneMoney
  • Morses Club
  • Boon
  • Holvi

Аналитики отмечают, что в столь масштабных проблемах виновато не только руководство Wirecard, но также и аудитори из Ernst & Young, которые десятилетие не могли обнаружить мошенничество.

Что все это значит для инвесторов


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

В частности, начинающим инвесторам имеет смысл:

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


Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

Recovery mode ICL Services и SimpleOne стали официальными партнерами

29.07.2020 12:21:28 | Автор: admin
Системный интегратор ICL Services заключил соглашение осотрудничестве сроссийской компанией-разработчиком SimpleOne.


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

Продукты SimpleOne разработаны сучетом современных тенденций нарынке ESM-систем: для разработки собственных процессов доступны low- иno-code инструменты; интерфейс удобен ипонятен для пользователей; есть возможность масштабировать решение под нагрузки крупных клиентов.

Илья Жакашев, директор поразвитию бизнеса SimpleOne:

&laquo; Заключая партнерское соглашение сICLServices, мырасширяем возможности продвижения продукта SimpleOne вРоссии изарубежом. Одной изприоритетных задач для нас сейчас является развитие регионального присутствия. Вэтом плане партнерство сICL Services открывает для SimpleOne новые горизонты. Уверен, что наше сотрудничество послужит импульсом для развития обеих компаний.

Сергей Камаев, менеджер кросс-функциональных процессов компании ICLServices:

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

Дополнительная информация



SimpleOne разработчик программного обеспечения для автоматизации бизнес-процессов всех подразделений компании, занимающихся процессной ипроектной деятельностью вобласти оказания услуг.
Платформа SimpleOne помогает распространить лучшие практики оказания иуправления услугами (ITIL, VeriSM) навсе сервисные подразделения компании. Сквозная автоматизация позволит унифицировать услуги иполучить единый инструмент оркестрации. Наличие коробочных программных продуктов для IT, ИБ, HR, АХО идругих департаментов существенно сократит сроки истоимость внедрения решения.

https://simpleone.ru/

Дополнительная информация для СМИ:
e-mail: hello@simpleone.ru
тел.: +7 (495) 181 85 08

ICL Services крупный системный интегратор (входит вгруппу компаний ICL), предоставляющий полный комплекс сервисных услуг наотечественном имеждународном рынках. Вштате компании более 2000сотрудников, успешно взаимодействующих сболее чем 80клиентами из30стран мира, оказывающих ИТ-сервисные услуги 24часа 7дней внеделю нарусском, английском, французском инемецком языках. Офисы ICL Services расположены вКазани, Москве, Воронеже, Владивостоке иБелграде (Сербия). Среди клиентов компании: Ozon, Ренессанс Капитал, Kelly Services, Spring Mobile Solutions, YUM!Brands идругие крупные игроки рынка.

www.icl-services.com

Дополнительная информация для СМИ:
e-mail: arina.vasilieva@icl-services.com
тел.: 8(800)333-98-70
Подробнее..

Из песочницы Автоматизация бюджетирования что это, с какими проблемами связано и какие программные продукты использует?

01.08.2020 14:17:18 | Автор: admin
Это вводная статья о том, что такое автоматизация бюджетирования, о каких проблемах говорят, когда используют это словосочетание, и какие IT-инструменты используются в ней.

Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем вам сюда.

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

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

Почему я решил ее написать?


Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:

  1. В чем специфические проблемы автоматизации бюджетирования? Чем она отличается от автоматизации обычного учета?
  2. Чем отличаются между собой модные программные продукты (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, Бит.Финанс, 1С: УХ) и по какому принципу они построены?
  3. Почему BI не основной инструмент автоматизации бюджетирования?

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

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

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

  • Архитектура (взаимодействие с аппаратной частью и другими модулями учета и планирования)
  • Функциональность
  • UX: интуитивность, понятность, простота настройки
  • Стоимость внедрения / владения


Проблемы и принципы их решения


Методология: Что такое бюджетирование и как оно связано с управленческим учетом
Понятие Управленческий учет можно рассматривать в двух вариантах: 1) многоуровневая система фактического учета 2) многоуровневая система фактического учета и планирования. При этом управленческий учет ведется и в финансовом, и в нефинансовом выражении (на низших уровнях чаще используются натуральные показатели, а финансовые показатели важны на верхних). Бюджетами же обычно называют верхнеуровневые финансовые планы.

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

У сферы бюджетирования две основные функции:

  • Составить план
  • Сопоставить план с фактом

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


Архитектурные отличия между учетом и бюджетированием заключаются в том, что данные учета идут снизу вверх. Чтобы получить качественную отчетность, нужно организовать запись как можно более детальных фактов. Тогда любую сводную информацию (важную для руководителей) можно будет получить простой агрегацией.

Поэтому в учете оптимально работает схема Документ > Таблица (Регистр) > Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).


Рис. 1. Учетная схема Документ > Регистр > Отчет

Пример реализации

Рис. 2

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

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


Рис. 3

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

Проблема 2: Скорость сбора факта. Планы выводятся в отчеты очень быстро (поскольку хранятся в уже укрупненном виде), а фактические данные вычисляются очень медленно.

Проблема 3: Формы ввода планов . Самой удобной формой ввода планов является план-факт отчет. Но отчеты в информационных системах обычно не позволяют вводить данные.

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

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

Проблема 1: Администрирование правил трансформации


На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.

Это плохо:

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

Сложность правил трансформации


Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения к организации; от склада к региону; от номенклатуры товара к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.

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

При этом:

  • если закупается номенклатура Горюче-смазочные материалы у поставщика ООО Прямоугольник и по договору Договор 25 это одна статья бюджета;
  • если ГСМ закуплены у другого поставщика; или даже у того же поставщика, но по другому договору это уже другая статья бюджета.


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

Решение проблемы 1: mapping


Для решения этой задачи mapping соответствия между полями разных уровней и/или видов учета и отчетности можно вынести из отчетов, создать как отдельный объект, настраивать и хранить отдельно, и затем обращаться к ним при необходимости.


Рис. 4

Это дает сразу два преимущества:

  • Правила проще администрировать. Их можно сделать интерактивными и настраивать без кода, а значит это зачастую могут делать даже обычные пользователи;
  • Одно правило можно использовать в разных отчетах и/или других алгоритмах

Значимых минусов у такого подхода нет.

Но разработать инструмент для удобного маппинга больших объемов справочников непросто.

Проблема 2: Скорость трансформации фактических данных


Решение проблемы 2: хранение трансформированных данных


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

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

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


Рис. 5

DWH


С этой проблемой связана сфера Хранилищ данных (DWH).

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

Какие плюсы:

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

Минусы:

  • Точность. На самом деле, этот минус скорее теоретический (максимальная точность обеспечивается именно когда мы берем данные из самого первичного источника информации).
    На практике
    Если в первичном учете данные ведутся качественно и хранилище выстроено качественно, то и в нем данные будут достаточно точными; если же первичный учет ведется плохо, то и без хранилищ в отчеты будут выводиться некорректные данные. То есть, потеря в доли процента в качестве данных после перехода к хранению агрегатов действительно возможна, но в большинстве случаев для компаний такие потери не являются значительными, чтобы принимать их во внимание.
  • Загрузка памяти. Соответственно, чтобы хранить агрегированные данные, мы тратим лишнее место на жестких дисках. Тоже, на самом деле, скорее теоретический минус.
  • Расшифровка. Если мы подключаем отчеты к агрегированным таблицам (в которых данные не детализированы по исходным документам), возникают проблемы с возможностями их расшифровки (drill-down).

ETL-процессы


ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).

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

У такого подхода есть плюсы:

  • Распределение нагрузки на систему. Процесс трансформации растягивается во времени. Мы можем заполнять агрегированную таблицу постепенно (по мере изменения/добавления данных в исходных учетных системах) или по расписанию. Например, сложные вычисления можно откладывать на ночь или другое нерабочее время, когда сервер свободнее. Это позволяет управлять нагрузкой на систему.
  • Однократность трансформации. Однажды записав сводную информацию в агрегированную таблицу, мы сможем обращаться к ней из множества разных отчетов. Поэтому одни и те же трансформации не придется выполнять множество раз.

Минус же один:

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

Проблема 3: Форма ввода бюджетов


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

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

То есть, если мы выстроили детальный учет по товарам (как показано в документе на рис. 2), обычно нет ни потребности, ни смысла вводить фактические данные в таком укрупненном виде, как они выглядят в отчете на том же рис. 2.

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

А вот для бюджетирования классическая схема Форма ввода (документ) > внутренние таблицы > Форма вывода (отчет) не подходит.

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

Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).

Минусы этого подхода очевидны
Первое. Нам придется разработать два технически разных объекта (отчет по закупкам и форма для планирования закупок), которые внешне должны быть идентичны.

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

Второе. При вводе плана хочется видеть факт. А если отчета и ввода разные объекты, делать это неудобно.

Решение проблемы 3: интерактивные формы ввода-вывода


Решение тоже очевидно: вместо привычных документов и отчетов, нужно создать объект, который позволит одновременно и читать, и вводить данные.

Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными то есть, работать наподобие того, как позволяет работать Excel.

При этом планы после ввода можно складывать в то же самое хранилище данных, где лежат фактические данные (см. рисунок).


Рис. 6

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

Степень интерактивности может быть разной: проще реализовать заранее настроенные формы, сложнее динамические (где заранее неизвестно количество колонок/строк, но заранее заданы их типы). Еще сложнее позволять в пользовательском режиме вращать данные, строить новые формы и задавать произвольные формулы расчета, меняя структуру отчетов.

Решение проблемы 4: кубы


Есть и еще один инструмент, который решает проблему, не обозначенную выше.
Дело в том, что при больших объемах данных, при высокой интерактивности и при сложных формулах, обычные реляционные SQL-таблицы, в которых принято хранить данные ERP-систем, не обеспечивают максимальной скорости обработки данных в режиме реального времени.

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

Что такое кубы?
Куб, OLAP-куб, OLAP-таблица, многомерная база данных, аналитическая база данных, столбцовая база данных это название способов хранения данных, позволяющих хранить их сразу на пересечении множества разрезов. Из таких таблиц проще получать срезы, а также они быстрее проводят быстрые калькуляции (например, распределение затрат в различных разрезах). Поэтому они подходят для анализа Что-если позволяют моделировать разные сценарии бизнеса и тут же получать ответ, как при изменении одних показателей изменятся другие.

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

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

Виды программных продуктов в бюджетировании


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

  • Системы исходных данных (системы учета, ERP-системы)
  • ETL-инструменты
  • Хранилища данных (обычные и OLAP-кубы)
  • BI-системы
  • EPM-системы
  • Конечно же, Excel

У каждого вида систем есть теоретически основная функция (см. таблицу):



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



Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно.

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

Поэтому, например, при максимальной потребности в DWH в компании, приобрести EPM-систему будет недостаточно, и лучше строить отдельную DWH; отдельная BI система может обладать более гибкими и шустрыми возможностями визуализации, чем комплексное EPM-решение и так далее.

Карта видов ПО в бюджетировании


В целом, визуально покрытие разных задач по автоматизации бюджетирования, разными типами информационных систем, можно показать приблизительно так:


Рис. 7

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

Бюджетирование в ERP-системах


Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.

На мой взгляд, классический функционал ERP включает учетную систему; конструкторы отчетов; функции оперативного контроля планов и, конечно же, базовые возможности их ввода.

Не включает: возможность сбора данных из множества источников; построение кубов и интерактивной аналитики

Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.

1C: УПП


В УПП реализована следующая схема, но внутри одной базы.


Рис. 8. Архитектура бюджетирования в 1С: УПП

Плюсы бюджетирования в УПП:

  • УПП очень прозрачна и легко дорабатывается. В ней легко выверять данные и достаточно недорого разрабатывать новый функционал.

Mapping в УПП на среднем уровне. Это не плюс и не минус. Настройка средней трудоемкости.

Недостатки бюджетирования в УПП:

  • Отсутствие интерактивных форм ввода-вывода. Создание любых данных выполняется через документы (ввод планов; получение агрегированных фактических данных; проведение калькуляций), где нет и не может быть интерактивности и возможности видеть общую картину.
  • Отсутствие ETL-интерфейса. Маппинг есть, но загрузка фактических данных происходит прямо из формы документа, что неудобно.
  • Старая платформа. Нельзя использовать технологию Управляемые формы 1С, которая дает пользователю современные возможности универсальной фильтрации/сортировки списков и отчетов. Это ухудшает аналитические возможности пользователя.

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

1C:ERP


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


Рис. 9. Архитектура бюджетирования в 1С:ERP

Плюсы бюджетирования в 1С:ERP:

  • Достаточно функциональные формы ввода-вывода

Недостатки бюджетирования в 1C:ERP:

  • Жесткость модели. В принципе, как и в большинстве ERP-систем, бюджетная модель не терпит частых изменений и достаточно придирчива к предварительной настройке
  • Слабый mapping. Почему-то функционал мэппинга хуже, чем в УПП
  • Жесткость продукта. В отличие от УПП, здесь перерабатывать каркас методологии крайне сложно и дорого. Нужно хорошо изучить существующую, и строить бюджетирование на ERP, если она действительно подходит компании
  • Производительность. Интерактивные формы достаточно функциональны, но техническое устройство делает их крайне медленными на больших объемах данных

Также в 1C:ERP нет серьезного функционала по части настройки организационного процесса бюджетирования (workflow) и многопользовательской работы. Например, процессы согласования вынесены в отдельный продукт 1С: Документооборот, который обычно внедряется поверх ERP.

1C: КА


Комплексная автоматизация представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.

MS Axapta / MS Dynamics AX


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


Рис. 10. Архитектура бюджетирования в MS Dynamics

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

Плюсы:

  • Интегрированность с учетными модулями. Настройка получения фактических данных из различных модулей ERP-системы достаточно проста.
  • Интеграция. Достаточно много возможностей для загрузки готовых планов из внешних систем. Таким образом, Microsoft четко следует логике отделения EPM от ERP, вследствие чего EPM-системы очень хорошо навешиваются на Dynamics
  • Workflow. Достаточно функциональная и прозрачная настраиваемая организационная модель бюджетного процесса

Минусы:

  • ETL. В целом продукт не предоставляет значимых возможностей трансформации данных
  • Жесткость продукта. Здесь задана готовая, но достаточно ограниченная методология. И (как и в случае с 1C:ERP) дорабатывать ее не только сложно, но и практически бессмысленно.

SAP S4 HANA


Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.

Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать EPM-системой поверх ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему SAP S4 HANA Cloud. Подробнее о SAP BPC будет ниже.

Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).

Таким образом, SAP переходит к архитектуре, противоположной той, что сегодня хорошо известна в обычной практике: в нем аналитическая база данных строится не над храналищем (SAP BW), а реализована под ERP-системой. При этом хранилище данных (SAP BW), когда пользователь работает с его данными из EPM-системы, передает данные для вычислений обратно в эту исходную комбинированную базу.

Фактически, тот же эффект, ради которого задумывались IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.

Oracle Cloud ERP


Oracle также пошла по пути встраивания EPM-системы внутрь ERP.

Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion, компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.

BI-системы


BI-системы (Business Intellegence) в чистом виде это средство вывода данных. То есть, BI это конструкторы отчетов и дашбордов, которые также содержат базовые функции реструктуризации и анализа данных (например, соединять таблицы, находить усредненные тренды и т.д.).

Популярные BI-системы:

  • Power BI
  • Tableau
  • QlikView / QlikSense
  • IBM Cognos TM1
  • SAP BusinessObjects

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

EPM-системы


EPM сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).

Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных План-факт форм. Понятие EPM еще не стало общеизвестным, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте Business Intellegence, корректнее называть именно EPM-системами.

Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), но мы будем рассматривать их именно в части систем для автоматизации бюджетирования. Поэтому мы будем называть SAP Business Planning & Consolidation (SAP BPC) EPM-системой, хотя сам SAP называет ею более крупный продукт SAP EPM, в который включается BPC.

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

Известные EPM-системы:

  • Oracle Hyperion
  • IBM Planning Analytics
  • Anaplan
  • SAP BPC
  • Бит.Финанс
  • 1C: Управление холдингом

Начнем с маленьких.

Бит.Финанс


Бит.Финанс основан на методологии бюджетирования УПП, однако он поддерживается, развивается, и кроме того реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из разных внешних источников).


Рис. 11. Архитектура бюджетирования в Бит.Финанс

Плюсы автоматизации бюджетирования в Бит.Финанс:

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

Mapping как в УПП. На среднем уровне.

Недостатки автоматизации бюджетирования в Бит.Финанс:

  • Работа через формы учетных документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования архитектурно неправильно и неудобно.
  • Отсутствие интерактивных форм ввода-вывода. В отличие от 1C:ERP, здесь их нет.

Anaplan


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

В отличие от остальных популярных решений (в т.ч. Hyperion и Planning Analytics), имеет немного специфическую специализацию: он лучше всего работает как интерактивный калькуляционный сервис, который позволяет быстро автоматически пересчитывать объемные бюджетные модели с большим количеством зависимостей.


Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)

Плюсы:

  • Калькуляция. Продукт сфокусирован на вычислениях, и хранит все данные в In-Memory OLAP, что позволяет пересчитывать все модели в режиме онлайн
  • Коллективная работа (в рамках подготовки плановых данных)
  • UX и произвольное моделирование.
  • ETL. Собственный и достаточно удобный ETL-инструмент
  • Требует минимальной IT-поддержки. Особенно по части моделирования
  • Стоимость. Дороговата для российского рынка, но в сравнении с международными лидерами (тем же Oracle Hyperion) полная стоимость владения выходит ниже
  • Скорость внедрения. В сравнении с Hyperion и Planning Analytics, продукт проще и в использовании, и во внедрении

Минусы:

  • Форматирование
  • Коллективная работа (в части работы с событиями: уведомления, рассылки и пр.)
  • Собственный синтаксис формул. Вообще использование собственного кода всегда недостаток с точки зрения конечных пользователей.
  • Иерархии. Раньше были проблемы с использованием разной иерархии справочника для разных бюджетных моделей. Проблема неважна для многих компаний, но критична для отдельных. Возможно (я надеюсь на это) к данному моменту Anaplan уже решил эту проблему.
  • Ad-hoc отчетность. Вообще это скорее специализация, чем недостаток: Anaplan в большей мере ориентирован на работу через моделирование, чем на быструю аналитику и репортинг.
  • Ограниченные возможности для масштабирования


И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс этого в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа Что-Если, расчета и утверждения планов (бюджетов), и планировать архитектуру заказчикам нужно исходя из этого. Минус в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.

В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможности легко перегонять данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (с учетом тарификации в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.

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


Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)

В целом, использование одновременно EPM и BI-систем является нормальной практикой.

Oracle Hyperion


Поставляется в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.

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


Рис. 14. Архитектура бюджетирования в Hyperion (пример)

На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.

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

Плюсы автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. В случае с Oracle отмечу как плюс, поскольку Oracle один из крупнейших поставщиков баз данных, и интеграция для компаний, кто работает на Oracle СУБД (а таких компаний много), действительно дает преимущества. В частности, удобнее распределять функционал между облаком и сервером. Кроме того, коллеги говорят о достаточно серьезных преимуществах по части безопасности в Oracleовой архитектуре (в этом я не специалист, если здесь таковые есть просьба поправить).
  • Ad-hoc (отчетность по запросу).

Недостатки автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. Отмечу и как минус, поскольку, по имеющейся информации, Hyperion выбирается в основном именно компаниями, работающими на стеке технологий Oracle, и от его использования в не-Oracleовой среде в долгосрочной перспективе возможен меньший эффект.
  • Калькуляции. Продукт в меньшей степени заточен на пересчеты моделей, чем тот же Anaplan.
  • Сложность. Продукт не слишком легкий и с точки зрения инфраструктурной нагрузки, и с точки зрения UX (требует высокой квалификации и подготовленности пользователей).

IBM Planning Analytics


В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognosа).

Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.

Типичная архитектура очень похожа на Hyperion.


Рис. 15. Архитектура бюджетирования в Planning Analytics (пример)

Сильные стороны IBM Planning Analytics:

  • Прогнозирование.
  • Работа с событиями.
  • Гибкость. Продукт нельзя назвать не требовательным к предварительной настройке, но он старается быть адаптированным к изменчивым моделям.
  • Неэкосистемность. Что удивляет в работе с IBM большой объем методических материалов, выпускаемых компанией, направлен на описание лучших практик взаимодействия продуктов IBM с другими решениями (в том числе, Oracle и SAP), причем в самых разных вопросах. На мой субъективный взгляд, хорошо, что в долгосрочной перспективе компания держит тренд на то, чтобы развивать интеграцию со сторонними системами (что позволяет поддерживать самые разные варианты сложившихся в компаниях архитектур), а не сокращать ее.
  • Поддержка продукта.

Минусы

  • Сложность. Как и Hyperion: требуется обучение пользователей, не самая легкая инфраструктура.

SAP BPC


В целом, отличительные особенности SAP экосистемность, сложность архитектуры и инфраструктуры решений.

Как я уже говорил, SAP в разное время поддерживал и поддерживает различные варианты архитектуры; по наиболее свежей информации, флагманская версия архитектуры, рекомендуемая вендором на сегодняшний день, выглядит так:


Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)

Преимущества бюджетирования на базе SAP BPC:

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

Недостатки бюджетирования на базе SAP BPC:

  • UX и гибкость. Как и практически все продукты SAP, решение для бюджетирования требует высокой квалификации рядовых пользователей, а также очень требовательно к трудоемким предварительным настройкам.
  • Инфраструктурная нагрузка. К тому же, SAP постоянно изменяет архитектуру. С одной стороны, это хорошо (компания ищет новые способы реализации задач), с другой стороны для компаний это часто оборачивается большими трудностями при переходе на новые версии. Например, несколько лет назад SAP стала активно отказываться от версии своего хранилища SAP BW для MS SQL Server, оставляя альтернативную ей версию NetWeaver; затем стала активно продвигать BW/4 HANA как замену NetWeaver; при этом сейчас тенденция идет к тому, что компания переводит фокус с EPC на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
  • Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.

Отмечу, что сейчас продукт активно замещается облачной SAP Analytics Cloud.

ETL-инструменты


Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения:

  • IBM DataStage
  • Informatica PowerCenter
  • Talend
  • Apatar
  • SAP Data Services
  • Oracle Data Integrator
  • Microsoft Azure Data Factory
  • и мн. др.

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

Из песочницы Автоматизация бюджетирования что это, с какими проблемами связано и какие программные продукты используются?

01.08.2020 18:14:38 | Автор: admin
Это вводная статья о том, что такое автоматизация бюджетирования, о каких проблемах говорят, когда используют это словосочетание, и какие IT-инструменты используются в ней.

Если вы хотите понять, как связаны между собой BI, хранилища данных (DWH), системы автоматизации бюджетирования (Cognos, Anaplan, 1С: Управление холдингом, Бит.Финанс) и чем они отличаются от других корпоративных информационных систем вам сюда.

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

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

Почему я решил ее написать?


Сейчас практически отсутствует краткое систематизированное описание этой области, которое давало бы понятные ответы на вопросы:

  1. В чем специфические проблемы автоматизации бюджетирования? Чем она отличается от автоматизации обычного учета?
  2. Чем отличаются между собой модные программные продукты (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, Бит.Финанс, 1С: УХ) и по какому принципу они построены?
  3. Почему BI не основной инструмент автоматизации бюджетирования?

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

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

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

  • Архитектура (взаимодействие с аппаратной частью и другими модулями учета и планирования)
  • Функциональность
  • UX: интуитивность, понятность, простота настройки
  • Стоимость внедрения / владения


Проблемы и принципы их решения


Методология: Что такое бюджетирование и как оно связано с управленческим учетом
Понятие Управленческий учет можно рассматривать в двух вариантах: 1) многоуровневая система фактического учета 2) многоуровневая система фактического учета и планирования. При этом управленческий учет ведется и в финансовом, и в нефинансовом выражении (на низших уровнях чаще используются натуральные показатели, а финансовые показатели важны на верхних). Бюджетами же обычно называют верхнеуровневые финансовые планы.

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

У сферы бюджетирования две основные функции:

  • Составить план
  • Сопоставить план с фактом

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


Архитектурные отличия между учетом и планированием заключаются в том, что данные учета идут снизу вверх. Чтобы получить качественную отчетность, нужно организовать запись как можно более детальных фактов. Тогда любую сводную информацию (важную для руководителей) можно будет получить простой агрегацией.

Поэтому в учете оптимально работает схема Документ > Таблица (Регистр) > Отчет (которая использовалась задолго до автоматизации, еще в средневековом бухучете).


Рис. 1. Учетная схема Документ > Регистр > Отчет

Пример реализации

Рис. 2

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

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


Рис. 3

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

Проблема 2: Скорость сбора факта. Планы выводятся в отчеты очень быстро (поскольку хранятся в уже укрупненном виде), а фактические данные вычисляются очень медленно.

Проблема 3: Формы ввода планов . Самой удобной формой ввода планов является план-факт отчет. Но отчеты в информационных системах обычно не позволяют вводить данные.

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

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

Проблема 1: Администрирование правил трансформации


На рис. 1-3 все правила трансформации фактических данных (от низшего уровня учета до верхних уровней отчетности) прописаны прямо в коде отчета.

Это плохо:

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

Сложность правил трансформации


Здесь очень важно учитывать, что правила трансформации действительно могут быть достаточно сложными. Далеко не всегда трансформация представляет простое укрупнение данных (от дня к месяцу; от подразделения к организации; от склада к региону; от номенклатуры товара к статье и т.д.). Особенно явно это встречается в СНГ, где управленческий учет часто ведется на основе бухгалтерского. Тогда из самых разных комбинаций разных реквизитов бухучета могут определяться разные значения для управленческого учета.

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

При этом:

  • если закупается номенклатура Горюче-смазочные материалы у поставщика ООО Прямоугольник и по договору Договор 25 это одна статья бюджета;
  • если ГСМ закуплены у другого поставщика; или даже у того же поставщика, но по другому договору это уже другая статья бюджета.


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

Решение проблемы 1: mapping


Для решения этой задачи mapping соответствия между полями разных уровней и/или видов учета и отчетности можно вынести из отчетов, создать как отдельный объект, настраивать и хранить отдельно, и затем обращаться к ним при необходимости.


Рис. 4

Это дает сразу два преимущества:

  • Правила проще администрировать. Их можно сделать интерактивными и настраивать без кода, а значит это зачастую могут делать даже обычные пользователи;
  • Одно правило можно использовать в разных отчетах и/или других алгоритмах

Значимых минусов у такого подхода нет.

Но разработать инструмент для удобного маппинга больших объемов справочников непросто.

Проблема 2: Скорость трансформации фактических данных


Решение проблемы 2: хранение трансформированных данных


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

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

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


Рис. 5

DWH


С этой проблемой связана сфера Хранилищ данных (DWH).

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

Какие плюсы:

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

Минусы:

  • Точность. На самом деле, этот минус скорее теоретический (максимальная точность обеспечивается именно когда мы берем данные из самого первичного источника информации).
    На практике
    Если в первичном учете данные ведутся качественно и хранилище выстроено качественно, то и в нем данные будут достаточно точными; если же первичный учет ведется плохо, то и без хранилищ в отчеты будут выводиться некорректные данные. То есть, потеря в доли процента в качестве данных после перехода к хранению агрегатов действительно возможна, но в большинстве случаев для компаний такие потери не являются значительными, чтобы принимать их во внимание.
  • Загрузка памяти. Соответственно, чтобы хранить агрегированные данные, мы тратим лишнее место на жестких дисках. Тоже, на самом деле, скорее теоретический минус.
  • Расшифровка. Если мы подключаем отчеты к агрегированным таблицам (в которых данные не детализированы по исходным документам), возникают проблемы с возможностями их расшифровки (drill-down).

ETL-процессы


ETL можно называть любой процесс, в котором данные берутся откуда-то, изменяются и затем куда-то загружаются. Это общепринятое сокращение от Extract (получить), Transform (преобразовать), Load (загрузить).

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

У такого подхода есть плюсы:

  • Распределение нагрузки на систему. Процесс трансформации растягивается во времени. Мы можем заполнять агрегированную таблицу постепенно (по мере изменения/добавления данных в исходных учетных системах) или по расписанию. Например, сложные вычисления можно откладывать на ночь или другое нерабочее время, когда сервер свободнее. Это позволяет управлять нагрузкой на систему.
  • Однократность трансформации. Однажды записав сводную информацию в агрегированную таблицу, мы сможем обращаться к ней из множества разных отчетов. Поэтому одни и те же трансформации не придется выполнять множество раз.

Минус же один:

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

Проблема 3: Форма ввода бюджетов


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

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

То есть, если мы выстроили детальный учет по товарам (как показано в документе на рис. 2), обычно нет ни потребности, ни смысла вводить фактические данные в таком укрупненном виде, как они выглядят в отчете на том же рис. 2.

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

А вот для бюджетирования классическая схема Форма ввода (документ) > внутренние таблицы > Форма вывода (отчет) не подходит.

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

Что остается делать? Можно создать форму для ввода планов, которая будет очень, очень похожа на этот отчет (что и было показано на рис. 3).

Минусы этого подхода очевидны
Первое. Нам придется разработать два технически разных объекта (отчет по закупкам и форма для планирования закупок), которые внешне должны быть идентичны.

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

Второе. При вводе плана хочется видеть факт. А если отчета и ввода разные объекты, делать это неудобно.

Решение проблемы 3: интерактивные формы ввода-вывода


Решение тоже очевидно: вместо привычных документов и отчетов, нужно создать объект, который позволит одновременно и читать, и вводить данные.

Еще лучше, если в этом объекте можно будет еще и выполнять расчеты между вводимыми и/или читаемыми данными то есть, работать наподобие того, как позволяет работать Excel.

При этом планы после ввода можно складывать в то же самое хранилище данных, где лежат фактические данные (см. рисунок).


Рис. 6

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

Степень интерактивности может быть разной: проще реализовать заранее настроенные формы, сложнее динамические (где заранее неизвестно количество колонок/строк, но заранее заданы их типы). Еще сложнее позволять в пользовательском режиме вращать данные, строить новые формы и задавать произвольные формулы расчета, меняя структуру отчетов.

Решение проблемы 4: кубы


Есть и еще один инструмент, который решает проблему, не обозначенную выше.
Дело в том, что при больших объемах данных, при высокой интерактивности и при сложных формулах, обычные реляционные SQL-таблицы, в которых принято хранить данные ERP-систем, не обеспечивают максимальной скорости обработки данных в режиме реального времени.

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

Что такое кубы?
Куб, OLAP-куб, OLAP-таблица, многомерная база данных, аналитическая база данных, столбцовая база данных это название способов хранения данных, позволяющих хранить их сразу на пересечении множества разрезов. Из таких таблиц проще получать срезы, а также они быстрее проводят быстрые калькуляции (например, распределение затрат в различных разрезах). Поэтому они подходят для анализа Что-если позволяют моделировать разные сценарии бизнеса и тут же получать ответ, как при изменении одних показателей изменятся другие.

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

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

Виды программных продуктов в бюджетировании


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

  • Системы исходных данных (системы учета, ERP-системы)
  • ETL-инструменты
  • Хранилища данных (обычные и OLAP-кубы)
  • BI-системы
  • EPM-системы
  • Конечно же, Excel

У каждого вида систем есть теоретически основная функция (см. таблицу):



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



Важно: Нужно обратить внимание, что обычно перекрытие функций не 100-процентно.

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

Поэтому, например, при максимальной потребности в DWH в компании, приобрести EPM-систему будет недостаточно, и лучше строить отдельную DWH; отдельная BI система может обладать более гибкими и шустрыми возможностями визуализации, чем комплексное EPM-решение и так далее.

Карта видов ПО в бюджетировании


В целом, визуально покрытие разных задач по автоматизации бюджетирования, разными типами информационных систем, можно показать приблизительно так:


Рис. 7

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

Бюджетирование в ERP-системах


Понятие ERP со временем меняется, и в ERP-системы включаются все новые возможности.

На мой взгляд, классический функционал ERP включает учетную систему; конструкторы отчетов; функции оперативного контроля планов и, конечно же, базовые возможности их ввода.

Не включает: возможность сбора данных из множества источников; построение кубов и интерактивной аналитики

Есть основания полагать, что понятие EPM (как и BI) задумывалось как нечто, выходящее за рамки ERP. Но сейчас границы стираются, и EPM-функции или даже целые продукты могут включаться в качестве модулей в ERP-системы.

1C: УПП


В УПП реализована следующая схема, но внутри одной базы.


Рис. 8. Архитектура бюджетирования в 1С: УПП

Плюсы бюджетирования в УПП:

  • УПП очень прозрачна и легко дорабатывается. В ней легко выверять данные и достаточно недорого разрабатывать новый функционал.

Mapping в УПП на среднем уровне. Это не плюс и не минус. Настройка средней трудоемкости.

Недостатки бюджетирования в УПП:

  • Отсутствие интерактивных форм ввода-вывода. Создание любых данных выполняется через документы (ввод планов; получение агрегированных фактических данных; проведение калькуляций), где нет и не может быть интерактивности и возможности видеть общую картину.
  • Отсутствие ETL-интерфейса. Маппинг есть, но загрузка фактических данных происходит прямо из формы документа, что неудобно.
  • Старая платформа. Нельзя использовать технологию Управляемые формы 1С, которая дает пользователю современные возможности универсальной фильтрации/сортировки списков и отчетов. Это ухудшает аналитические возможности пользователя.

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

1C:ERP


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


Рис. 9. Архитектура бюджетирования в 1С:ERP

Плюсы бюджетирования в 1С:ERP:

  • Достаточно функциональные формы ввода-вывода

Недостатки бюджетирования в 1C:ERP:

  • Жесткость модели. В принципе, как и в большинстве ERP-систем, бюджетная модель не терпит частых изменений и достаточно придирчива к предварительной настройке
  • Слабый mapping. Почему-то функционал мэппинга хуже, чем в УПП
  • Жесткость продукта. В отличие от УПП, здесь перерабатывать каркас методологии крайне сложно и дорого. Нужно хорошо изучить существующую, и строить бюджетирование на 1С:ERP, если она действительно подходит компании
  • Производительность. Интерактивные формы достаточно функциональны, но техническое устройство делает их крайне медленными на больших объемах данных

Также в 1C:ERP нет серьезного функционала по части настройки организационного процесса бюджетирования (workflow) и многопользовательской работы. Например, процессы согласования вынесены в отдельный продукт 1С: Документооборот, который обычно внедряется поверх ERP.

1C: КА


Комплексная автоматизация представляет собой урезанную версию 1С:ERP, поэтому ее развитие проходит по тому же пути, и собственной методологии бюджетирования здесь нет.

MS Axapta / MS Dynamics AX


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


Рис. 10. Архитектура бюджетирования в MS Dynamics

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

Плюсы:

  • Интегрированность с учетными модулями. Настройка получения фактических данных из различных модулей ERP-системы достаточно проста.
  • Интеграция. Достаточно много возможностей для загрузки готовых планов из внешних систем. Таким образом, Microsoft четко следует логике отделения EPM от ERP, вследствие чего EPM-системы очень хорошо навешиваются на Dynamics
  • Workflow. Достаточно функциональная и прозрачная настраиваемая организационная модель бюджетного процесса

Минусы:

  • ETL. В целом продукт не предоставляет значимых возможностей трансформации данных
  • Жесткость продукта. Здесь задана готовая, но достаточно ограниченная методология. И (как и в случае с 1C:ERP) перерабатывать ее не только сложно, но и практически бессмысленно.

SAP S4 HANA


Основной продукт SAP, пришедший на смену ERP-системе SAP R/3.

Для бюджетирования сейчас используется отдельный EPM-продукт, который в десктопной версии (SAP BPC) еще можно было считать отдельной EPM-системой поверх ERP, но в облачной версии (SAP Analytics Cloud) уже окончательно встроен в ERP-систему (в SAP S4 HANA Cloud). Подробнее о SAP BPC будет ниже.

Про саму S/4 HANA важно сказать другое: SAP переводит всю работу ERP-системы с реляционной базы данных на комбинированную (смесь реляционной, колоночной и многомерной). Такой комбинированной базой данных выступает собственная технология SAP HANA (не путать с S/4 HANA), которая в зависимости от действий пользователя работает то как транзакционная (учетная система), то как аналитическая система (куб).

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

Фактически, тот же эффект, ради которого задумывались IN-Memory OLAP, SAP достигает противоположным способом: максимальным вынесением калькуляций из оперативной памяти.

Oracle Cloud ERP


Oracle также пошла по пути встраивания EPM-системы внутрь ERP.

Компания активно переводит свои продукты на облачную версию (возможно, даже активнее, чем это делает SAP). Поэтому для своего главного EPM-решения, Oracle Hyperion (о котором мы тоже поговорим ниже), компания продвигает альтернативу в виде облачного Oracle EPM Cloud, который включается в состав облачной Oracle Cloud ERP.

BI-системы


BI-системы (Business Intellegence) в чистом виде это средство вывода данных. То есть, BI это конструкторы отчетов и дашбордов, которые обычно также содержат базовые функции реструктуризации и анализа данных (например, позволяют соединять таблицы, находить усредненные тренды и пр.).

Популярные BI-системы:

  • Power BI
  • Tableau
  • QlikView / QlikSense
  • IBM Cognos TM1
  • SAP BusinessObjects

Как правило, BI подключается к хранилищам данных (как реляционным, так и многомерным) или к исходным SQL-таблицам. Таким образом, можно обращаться к достаточно детализированным исходным данным (чтобы укрупнять их уже в BI). Однако, сложные условные трансформации (с условиями если) это не про классический функционал BI. Если перед вами стоит задача построить систему визуализации дашбордов, лучше постройте трансформацию перед тем как внедрять BI.

EPM-системы


EPM сокращенно Enterprise Performance Management (управление эффективностью предприятия). Также встречаются термины Corporate performance management (CPM) и реже Business performance management (BPM).

Довольно широкий термин, который может подразумевать и смежные функции, однако чаще всего такие системы можно рассматривать как конструкторы интерактивных План-факт форм. Понятие EPM еще не стало общеизвестным, но такие решения, как IBM Planning analytics, Oracle Hyperion, Anaplan, которые иногда рассматривают в контексте Business Intellegence, корректнее называть именно EPM-системами.

Иногда EPM-системы создаются для более широких целей (например, SAP EPM или 1С: Управление холдингом), но мы будем рассматривать их именно в части систем для автоматизации бюджетирования. Поэтому мы будем называть SAP Business Planning & Consolidation (SAP BPC) EPM-системой, хотя сам SAP называет так более крупный продукт SAP EPM, в который включается SAP BPC.

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

Известные EPM-системы:

  • Oracle Hyperion
  • IBM Planning Analytics
  • Anaplan
  • SAP BPC
  • Бит.Финанс
  • 1C: Управление холдингом

Начнем с маленьких.

Бит.Финанс


Бит.Финанс основан на методологии бюджетирования УПП, однако, в отличие от него, во-первых, поддерживается и развивается, а во-вторых, реализован как EPM-система поверх ERP (таким образом, позволяет консолидировать фактические данные из разных внешних источников).


Рис. 11. Архитектура бюджетирования в Бит.Финанс

Плюсы автоматизации бюджетирования в Бит.Финанс:

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

Mapping как в УПП. На среднем уровне.

Недостатки автоматизации бюджетирования в Бит.Финанс:

  • Работа через формы учетных документов. Несмотря на то, что формы документов стали гибкими (см. первый плюс), и в целом в этом аспекте сделан большой прогресс по сравнению с УПП, продукт все же не ушел от документно-ориентированной модели работы настолько далеко, насколько хотелось бы. Что, как мы сказали, для бюджетирования архитектурно неправильно и неудобно.
  • Отсутствие интерактивных форм ввода-вывода. В отличие от 1C:ERP, здесь их нет.

Anaplan


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

В отличие от остальных популярных решений (в т.ч. Hyperion и Planning Analytics), имеет немного специфическую специализацию: он лучше всего работает как калькуляционный сервис, который позволяет быстро автоматически пересчитывать объемные бюджетные модели с большим количеством зависимостей.


Рис. 12. Архитектура бюджетирования в Anaplan (популярный сценарий автоматизации)

Плюсы:

  • Калькуляция. Продукт сфокусирован на вычислениях, и хранит все данные в In-Memory OLAP, что позволяет пересчитывать все модели в режиме онлайн
  • Коллективная работа (в рамках подготовки плановых данных)
  • UX и произвольное моделирование.
  • ETL. Собственный и достаточно удобный ETL-инструмент
  • Требует минимальной IT-поддержки. Особенно по части моделирования
  • Стоимость. Дороговато для российского рынка, но в сравнении с международными лидерами (тем же Oracle Hyperion) полная стоимость владения выходит ниже
  • Скорость внедрения. В сравнении с Hyperion и Planning Analytics, продукт проще и в использовании, и во внедрении

Минусы:

  • Форматирование
  • Коллективная работа (в части работы с событиями: уведомления, рассылки и пр.)
  • Собственный синтаксис формул. Вообще использование собственного кода всегда недостаток с точки зрения конечных пользователей.
  • Иерархии. Раньше были проблемы с использованием разной иерархии справочника для разных бюджетных моделей. Проблема не важна для многих компаний, но критична для некоторых. Возможно (я надеюсь на это), к данному моменту Anaplan уже решил эту проблему.
  • Ad-hoc отчетность. Вообще это скорее специализация, чем недостаток: Anaplan в большей мере ориентирован на работу через моделирование, чем на быструю аналитику и репортинг.
  • Ограниченные возможности для масштабирования


И плюсом, и минусом Anaplan является его относительно четкая специализация и то, что он не покушается на IT-экосистему компании. Плюс в том, что продукт четко определился со своим функциональным назначением, и направления его развития достаточно предсказуемы. Он представляет собой сервис для проведения анализа Что-Если, расчета и утверждения планов (бюджетов), и планировать архитектуру заказчика нужно исходя из этого. Минус в том, что продукт не может заменить полноценное корпоративное хранилище данных, не может заменить все возможности BI, на нем не строят сложную корпоративную ETL-инфраструктуру, да и всю систему корпоративных вычислений. Все это не было бы проблемой, если бы продукт не предлагался только в облачной версии.

В отличие от Oracle и SAP (которые как раз претендуют на экосистемность), Anaplan не делает упор на возможность легко перегонять данные и инструменты между облаком и серверами компании. Таким образом, в его случае недостатки облачного продукта (с учетом тарификации в зависимости от объема используемых на сервере данных) проявляются наиболее заметно.

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


Рис. 13. Архитектура бюджетирования в Anaplan (альтернативный сценарий автоматизации)

В целом, использование одновременно EPM и BI-систем является нормальной практикой.

Oracle Hyperion


Поставляется минимум в двух версиях: Oracle Hyperion Planning и Oracle Hyperion Financial Management.
Сейчас активно замещается новым продуктом Oracle EPM Cloud.

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


Рис. 14. Архитектура бюджетирования в Hyperion (возможный вариант)

На рисунке я привел BI-систему в качестве примера, поскольку аналитическая база данных Oracle Essbase является отличной базой для аналитики больших массивов данных в BI-инструментах.

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

Плюсы автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. В случае с Oracle отмечу как плюс, поскольку Oracle один из крупнейших поставщиков баз данных, и интеграция для компаний, кто работает на Oracle СУБД (а таких компаний много), действительно дает преимущества. В частности, удобнее распределять функционал между облаком и сервером. Кроме того, коллеги говорят о достаточно серьезных преимуществах по части безопасности в Oracleовой архитектуре (в этом я не специалист, если здесь таковые есть просьба поправить).
  • Ad-hoc (отчетность по запросу).

Недостатки автоматизации бюджетирования в Oracle Hyperion:

  • Экосистемность. Отмечу и как минус, поскольку, по имеющейся информации, Hyperion выбирается в основном именно компаниями, работающими на стеке технологий Oracle, и от его использования в не-Oracleовой среде в долгосрочной перспективе возможен меньший эффект.
  • Калькуляции. Продукт в меньшей степени заточен на пересчеты моделей, чем тот же Anaplan.
  • Сложность. Продукт не слишком легкий и с точки зрения инфраструктурной нагрузки, и с точки зрения UX (требует высокой квалификации и подготовленности пользователей).

IBM Planning Analytics


В основном предназначенная для крупного бизнеса, не слишком простая в развертке и администрировании, но весьма функциональная EPM-система. Сейчас IBM Planning analytics строится на базе технологий TM1 (лежащих в основе Cognosа).

Для ETL-процессов IBM предлагает использовать отдельный продукт IBM DataStage (ранее применялся Cognos DataManager), Turbo Integrator, Cognos Integration Server или внешний ETL-инструмент.

Типичная архитектура очень похожа на Hyperion.


Рис. 15. Архитектура бюджетирования в Planning Analytics (возможный вариант)

Сильные стороны IBM Planning Analytics:

  • Прогнозирование.
  • Работа с событиями.
  • Гибкость. Продукт нельзя назвать не требовательным к предварительной настройке, но он старается быть адаптированным к изменчивым моделям.
  • Неэкосистемность. Что удивляет в работе с IBM большой объем методических материалов, выпускаемых компанией, направлен на описание лучших практик взаимодействия продуктов IBM с другими решениями (в том числе, Oracle и SAP), причем в самых разных вопросах. На мой субъективный взгляд, хорошо, что в долгосрочной перспективе компания держит тренд на то, чтобы развивать интеграцию со сторонними системами (что позволяет поддерживать самые разные варианты сложившихся в компаниях архитектур), а не сокращать ее.
  • Поддержка продукта.

Минусы

  • Сложность. Как и в случае с Hyperion: требуется значительное обучение пользователей, не самая легкая инфраструктура.

SAP BPC


В целом, отличительные особенности SAP экосистемность, сложность архитектуры и инфраструктуры решений.

Как я уже говорил, SAP в разное время поддерживал и поддерживает различные варианты архитектуры; по наиболее свежей информации, флагманская версия архитектуры, рекомендуемая вендором на сегодняшний день, выглядит так:


Рис. 15. Архитектура бюджетирования в SAP Business Planning & Consoldation (пример)

Преимущества бюджетирования на базе SAP BPC:

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

Недостатки бюджетирования на базе SAP BPC:

  • UX и гибкость. Как и практически все продукты SAP, решение для бюджетирования требует высокой квалификации рядовых пользователей, а также очень требовательно к трудоемким предварительным настройкам.
  • Инфраструктурная нагрузка. К тому же, SAP постоянно изменяет архитектуру. С одной стороны, это хорошо: разработчики ищут новые способы реализации задач. С другой стороны, для компаний это создает трудности при переходах на новые версии. Например, несколько лет назад SAP стала активно отказываться от версии своего хранилища SAP BW для MS SQL Server, оставляя альтернативную ей версию NetWeaver; затем стала активно продвигать BW/4 HANA как альтернативу NetWeaver; сейчас тенденция идет к тому, что компания переводит фокус с десктопной EPM-системы на облачную версию SAP Analytics Cloud, переход на которую также требует некоторого перестроения архитектуры.
  • Цена. С точки зрения полной стоимости владения, фактически оказывается одной из наиболее дорогостоящих EPM-систем в мире, на что влияют в том числе изменения в архитектуре.


ETL-инструменты


Для построения ETL-процессов используют известные ETL-инструменты, среди которых множество продуктов тех же вендоров, что выпускают BI/EPM решения:

  • IBM DataStage
  • Informatica PowerCenter
  • Talend
  • Apatar
  • SAP Data Services
  • Oracle Data Integrator
  • Microsoft Azure Data Factory
  • и мн. др.

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

Гонка воображений как развивается финтех в России

04.08.2020 10:19:03 | Автор: admin
Почему финтех в России круче, чем на Западе, как скоро мы начнём управлять счетами через голосовых помощников и кто такие цифровые сотрудники? Всё это обсудили в рамках подкаста Большая Дата его ведущий, директор по технологиям больших данных Билайна Константин Рогов, и заместитель президента председателя правления банка ВТБ Вадим Кулик. В этом посте мы собрали самые интересные ответы Вадима, в которых он рассказал, как технари стали драйвером развития финтеха и как кризисы дали импульс к развитию этой отрасли.



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

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

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

Решились ли вы в ВТБ на какие-то изменения в период самоизоляции?

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

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

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

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

Звучит прогрессивно. Вообще интересно, что в целом в России банковская отрасль очень продвинутая. Помню, я как-то попытался в центре Берлина расплатиться смартфоном на меня посмотрели как на сумасшедшего. А в России в каком регионе ни окажусь любой предприниматель если не Apple Pay, то перевод на карту точно принимает. Как думаешь, почему так сложилось?

Финансовые сети в России развивались позже, чем в Европе и США. Формирование банковской отрасли совпало с периодом бурного развития технологий.
При этом в тот период (90-е) в России появилось достаточно много людей с хорошим техническим образованием и с высоким IQ, которые остались без работы. Банковскую отрасль в нашей стране сформировали бывшие технари с крутым фундаментальным образованием и опытом разработки инноваций.
Да я и сам бывший технарь.

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

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

Дальше больше. Появился фронт-мониторинг, затем фронт-платёж, после биометрия, компьютерное чтение

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

Хм Ну ладно Запад, а почему такой сценарий не повторился, скажем, в Восточной Европе?

У меня был опыт внедрения кредитных фабрик в Европе с построением моделей тогда же я понял, что их тормозит в развитии. Это отсутствие масштаба. То, что страна сама по себе маленькая, делает разработку и внедрение подобных систем нерентабельными. А использовать чужие системы они не могут, поскольку у каждой страны своё законодательство, свои локальные источники данных, специфическая структура хранения, своя система органов власти

Вернёмся к технологическому развитию чего нам стоит ожидать в будущем?

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

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

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

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

Надеюсь, что это светлое будущее с нативным банком без надоедливой рекламы наступит как можно скорее. А пока я вижу, что многие компании развивают экосистемы, партнёрства. Не так давно ВТБ и Ростелеком объявили о создании совместного предприятия по работе с данными. Чего вы ждёте от этой кооперации?

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

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

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

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

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

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

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

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

Именно. Но, повторюсь, главное команда.

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

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

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

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

Категории

Последние комментарии

© 2006-2020, personeltest.ru