Этим летом завершилось официальное тестирование работы платформы 1С на СУБД Postgres Pro. В результате этого, фирма 1С официально объявила о внесении Postgres Pro в список поддерживаемых СУБД. Поэтому в докладе мы коснемся трех вариантов постгреса: свободно распространяемого PostgreSQL, и российских Postgres Pro Standard и Postgres Pro Enterprise. Первый из них для работы с 1С требует дополнительных патчей, Postgres Pro же работает с 1С "из коробки". Осенью 2017 года выходит "десятка" - 10-я версия PostgreSQL, и все основанные на нем продукты также ждёт много обновлений, часть из них имеет прямое отношение к использованию платформы 1С. В докладе будет рассказано, в частности, о:

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

В докладе будут разобраны причины торможения запросов с поисками по подстроке, возможности и подходы к оптимизации и ускорению подобных запросов. Этот функционал важен для компаний, в которых пользователи 1С ищут информацию по большим спискам данных по подстроке, например, подбор номенклатуры, поиск договоров и контрагентов, поиск физических и юридических лиц.
Также будут разобраны причины увеличения длительности записи и проведения «больших» документов (более 10000 строк), возможности по ускорению этих операций. Это критически важно в период сдачи отчетности, выполнение операций закрытия месяца и расчета себестоимости и подобных документов.

Блок расчета производственного и энергетического баланса:

1.Разработка механизма ввода плана производства
2.Разработка механизма ввода спецификаций (механизм расчета от объема выпускаемой продукции, механизм расчета ненормируемого потребления, механизм расчета от любых внешних параметров)
3.Разработка механизма ввода смет производственных расходов
4.Разработка механизма ввода смет общехозяйственных расходов
5.Разработка механизма ввода смет коммерческих расходов
6.Разработка механизма ввода смет прямых затрат
7.Разработка ввода цен на сырье с учетом ТЗР
8.Настройка спецификаций по объектам затрат
9.Ввод информации в сметы затрат
10.Расчет производственного и энергетического баланса

Блок расчета плановой себестоимости:

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

Блок контура управленческой отчетности:
1.Аналитическая отчетность
2.План-фактный анализ с рег.учетом

Чем отличается эффективная команда от обычной?
Можно назвать много отличительных черт хорошей команды: сплоченность членов команды, компетентность, вовлеченность и ответственность. Так и есть.
Но что является *критерием* эффективности команды? У меня есть собственное определение. Мне кажется, эффективность команды определяется умением справляться с проблемами. И *крутость* команды определяет масштаб проблем, которые она способна решать.
Крутые команды способны решать крутые проблемы. Здорово, если вы оказались в такой. А если нет? Исскуство лидера состоит в том, чтобы сделать из обычной среднестатистической группы людей невероятно крутую банду профи. А значит, научить команду решать любые проблемы.

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

1. Почему это до нас ни кто не делал.

2. Искусственный разум или "экспертная система" или...

3. Почему "я сейчас сварганю на коленке" неожиданно превратились в два года разработки...
3.1 два противополжных алгоритма
3.2 почему "год работы" оказался ни кому не нужен
3.3 ревью

4. Декомпозиция при анализе - плюсы и минусы (а так же что и как декомпозировать)
4.1 Глубина анализа
4.2 Неоднозначность рекомендаций - универсально не очень или эффективно но не для всех
4.3 Почему важно ранжировать значимость рекомендаций

5. Как мы выясняли - умнее ли наш алгоритм человека
5.1 Внутри команды
5.2 Публичный конкурс

6. Ожидаемые неожиданные форс-мажоры - чего мы предусмотреть не смогли и как боролись
6.1 Хранить или предрасчитывать
6.2 Памяти много не бывает
6.3 Инструкций ни кто не читает

7. Дорожная карта или  "стрижка только началась"

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

В своем докладе я расскажу:

Что такое план запроса. Зачем он вообще нужен?
Структура плана запроса. Все просто?
Поток операторов и поток данных. В чем разница?
Операторы доступа к данным. Их несколько?
Операторы соединения таблиц. И этих тоже несколько?
Как работает оптимизатор. При чем здесь статистика?
Ищем узкие места. Все сложно?

Доклад рассчитан в первую очередь на специалистов, которые хотят понять, как именно происходит исполнение запроса на уровне СУБД. Которые слышали, что есть "план запроса", но все не хватало времени разобраться, что же это такое.

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

План выступления:
1. Основные причины замедления работы БД 1С
    Краткое вступление. Перечисление основных причин замедления работы 1С: увеличение количества пользователей, усложнение конфигураций и платформы, прочее.
    Акцент на основных проблемах:
        1.1 Каждый сеанс отнимает ресурсы сервера, даже если пользователь не работает с ним
        1.2 Запросов к серверу много, время их выполнения становится все больше и больше, сервер не справляется с очередью запросов.
2. Способы ускорения - очевидные и нестандартные
    Очевидные - увеличение мощности серверов и инфраструктуры, оптимизация конфигураций 1С, настройка ПО.
    Нестандартные - пишем свой сверхтонкий веб-клиент для 1С и:
        2.1 Загружаем сервер только на время выполнения запроса
        2.2 Уменьшаем время выполнения одного запроса
        2.3 Уменьшаем количество запросов к 1С
3. Веб-сервисы как способ ускориться на порядок
    3.1 Развернутый ответ по пунктам 2.1, 2.2 и 2.3.
4. Интеграция с сайтом и дополнительное ускорение работы в 1С
    4.1 Одностраничное приложение на html+js+1C
    4.2 Кэширование данных в промежуточной базе на сайте
    4.3 Распределенные базы данных на 1С
5. Практика
    5.1 Статистика - отчет о нагрузочном тестировании сверхтонкого клиента для 1С:ITIL, работа 3000 пользователей в течение 12 часов.
    5.2 Разбор отчета. Выявление основных факторов ускорения работы: что зависит от платформы 1С, что от веб-сервера, от железа, от ПО и от алгоритмов конфигурации.
6. Дополнительные плюсы сверхтонкого веб-клиента
    6.1 Безопасность
    6.2 Кроссплатформенность
    6.3 Универсальные интерфейсы для мобильных устройств и десктопов
    6.4 Произвольный интерфейс
    6.5 Интеграция с сайтами
7. Выводы

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

1. Традиционная технология и ее узкие места, делающие ее, начиная с определенного уровня нагрузки, очень дорогой.

2. Особенности типового решения "Тест-центр", еще более удорожающие работу.

3. Для чего нам (партнерам) нужен нагрузочный тест - возврат к сути задачи.

4. Обход основных узких мест путем переноса работы с клиентских соединений на фоновые задания.

5. Обход архитектурных особенностей типового решения путем изменения способа управления сеансами.

6. Подтверждение жизнеспособности предложенных технологий: два отраслевых рекорда, успешно отработавшие тесты на 25000 потоков в прототипе и на 15000 - в ERP.

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

В основе динамической модели мотивации (ДММ) стоит предположение о том, что для организации важны четыре параметра прилагаемых работниками усилий:
- направление
- интенсивность, включая преодоление сопротивления
- равномерность
- продолжительность

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

Есть ряд принципов успешного взаимодействия в системе начальник- подчиненный.
Принцип синхронности. В системе лидер-команда принцип синхронности может проявиться в виде следующего правила: постоянно активный лидер получает пассивную команду. Активные люди не могут существовать в такой команде: они либо разрушают систему новыми идеями и неосознанными попытками перехвата управления, либо оказываются изгнанными.
Второе свойство системы лидер-команда – «зеркальность»
То, что находится в подсознании лидера, оказывается проявленным в групповом сознании и действиях команды, и наоборот (команда — «зеркало» руководителя, в котором отражаются его тайные страхи).
Третье свойство системы лидер-команда – «сопротивляемость изменениям». Система лидер-команда обладает способностью к самонастройке.

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

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

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

В связи с недавним учреждением фирмой 1С компании “1С International”, которая призвана работать на глобальном рынке автоматизации бизнеса, становятся актуальными вопросы вовлечение рядовых программистов 1С в глобальное разделение труда.
В основе доклада лежат некоторые тезисы из выступления на международной конференции “Discover ICT 2015” в Праге. Представляются новые материалы по англоязычным версиям программ на платформе 1С (1C:ERP, 1C:Small Business и др.) и по присутствующим на глобальном рынке игрокам. Даются оценки перспектив и рисков выхода на глобальный рынок, а также рекомендации для 1С-стартаперов.

Предварительные тезисы доклада:
1.    Требования и состояние глобального рынка автоматизации бизнеса:
1.1.    Клиенториентированность.
1.2.    Высокая конкуренция.
1.3.    Ожидание интуитивно понятных решений.
1.4.    Оперативная коммуникация.
2.    Обзор глобального рынка 1С:
2.1.    Решения, родившиеся на Западе.
2.2.    Решения для СНГ, уже адаптированные для Запада.
2.3.    Решения для СНГ, которые имеет смысл адаптировать для Запада в первую очередь, и как именно надо адаптировать (английская терминология, МСФО, SWIFT, Incoterms, SEPA, товаросопроводительная документация, интеграция с бухгалтерскими и платежными системами и др.).
3.    Объективные и субъективные проблемы в продвижении 1С на Запад:
3.1.    Достоинства и недостатки платформы 1С.
3.2.    Проблема курицы и яйца: нет решений на платформе 1С, потому что платформа непопулярна, а платформа непопулярна, потому что на ней нет решений. Как разорвать этот порочный круг?
3.3.    Английская бизнес-лексика.
3.4.    Прецедентное и континентальное право.
3.5.    Основные принципы работы на высококонкурентном рынке (компетенции, портфолио, бизнес-моделирование и др.).
4.    Предпосылки для продвижении 1С на Запад:
4.1.    Наработанная практика различных отраслевых решений.
4.2.    Огромный институт 1С-франчайзи и большой рынок труда программистов в странах бывшего СССР.
4.3.    Широкая русскоязычная диаспора.
4.4.    Опыт команды “1С International”.
5.    Рекомендации для глобальных 1С-стартаперов:
5.1.    Свободные и низкоконкурентные ниши на глобальном рынке.
5.2.    Регистрация компаний за рубежом.
5.3.    Зарубежные акселераторы и инкубаторы.
5.4.    Привлечение инвестиций: бизнес-ангелы, FFF, IPO, ICO, краудфандинг.

Хотелось бы затронуть несколько интересных тем, начнем с успешного проекта по переходу на платформу 8.3. Отвечу на вопрос каковы предпосылки проекта и кратко расскажу о нагрузочном тестировании платформы 8.3 на 10'000 пользователей.
Продолжим обсуждением такой дилеммы, как одновременное желание наращивать функционал для развития бизнеса  и естественным желанием сохранить общую работоспособность системы. Какие ошибки и почему совершали мы на этапе бурного развития функционала, какие сложности это вызывает сейчас.
Основной вопрос, который при этом возникает – а есть ли способ вообще не совершать ошибки? И если такого способа нет, то должна ли в вопросе борьбы с этими ошибками помогать и платформа 1С?

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

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

Часть "первая" - BI это просто
* неструктурированная информация в компании применяющей стэк технологий 1С
* математический аппарат готовый для использования в реальной жизни
* стоимость владения проектами BI в компании

Часть "вторая" - BI это деньги
* примеры показателей для бизнеса
* способы оптимизации бизнеса на основе BI
* подходы к обоснованию принятия решений

Часть "третья" - BI это коллектив
* обзор инструмента Dataiku - Collaborative Data Science Platform
* примеры использования Dataiku на базе данных учетных систем 1С
* разрешение конфликтов между математиками

Часть "четвертая" - BI запускается за неделю
* типовой план проекта по запуску в компании
* типовые ошибки менеджмента при запуске BI в компании

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

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

Вот примерный план доклада:
1. История неудач. Первые шаги по реализации проекта "Планирование в ГК".
2. Почему не получилось и что необходимо сделать чтобы проект масштаба ГК взлетел.
3. Важные этапы жизни проекта.
4. Детали проекта "Планирование в ГК".
    Стратегическое планирование. Коротко о главном.
    Планирование в маркетинге и продажах. Так ли уж важно точное планирование?
    Планирование в производстве. Как планировать загрузку производства.
    Планирование в снабжении. Как примерные планы продажников превратить в точные планы снабженцев.
5. Будущее проекта "Планирование в ГК".
6. Итоги. Основные тезисы.

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

План:
- Самые эффективные методы оптимизации правил конвертации;
- Методы поэтапного выполнения переносов данных (разделение выгрузки на части);
- EnterpriseData – универсальный формат обмена. Преимущества и главные недостатки;
- Особенности переноса документов в КД 2 (автоматическое проведение после загрузки);
- Проблемы совместимости программ 1С разных редакций (УПП и ERP, УТ 10 и УТ 11, БП 2 и БП 3);
- Самые популярные запросы пользователей и способы их решения:
    - Выгрузка только измененных данных;
    - Поля поиска объектов;
    - Отказ перезаписи существующих (найденных) объектов;
    - Отражение документов в регламентированном учете (особенности настройки);
    - Сверка ОСВ сразу после переноса;
    - Коды строк заказов в реализациях;
    - Сверка признака «Проведен» документов после завершения переноса;
    - Ошибка блокировок при переносе.

Разделы доклада:
1. Описание основных этапов проекта - состав работ, роли участников, риски. Состав проектной документации и её назначение.
2. Рабочие инструменты проектирования и управления проектами (на примере СППР, Redmine).
3. Применимость методологии Agile при внедрении сложных программных продуктов.

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

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

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

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

Вам нужно посетить доклад, если вы согласны с тезисами ниже:

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

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

- возможности и ограничения механизмов криптографии в платформе "1С:Предприятие 8";
- расширение возможностей криптографии платформы через технологию создания внешних компонент;
- функционал подсистемы "Электронная подпись" в конфигурации "1С:Библиотека стандартных подсистем";
- примеры использования криптографии в сервисах "1С-ЭДО" и "1С:ДиректБанк";
- разработка собственных решений с криптографией на платформе "1С:Предприятие 8";
- законодательство РФ по ЭП, практика применения;
- проблемы и способы их устранения при внедрении ЭП на предприятиях.

Один проект: 1С:ERP Управление предприятием 2 ( https://goo.gl/BpPDsk )
Один заказчик: АО «Красноярскнефтепродукт» ( http://knp24.ru/about/ )
Одна команда: БИТ:ERP (подразделение Первый БИТ, реализующее
масштабные проекты корпоративной автоматизации)
Две технологии управления: классическая проектная технология ("каскад") и scrum
Два результата: провал и успех

Все события и действующие лица - реальны. Любые совпадения не случайны ;)

Рассмотрим практику применении agile-принципов в привязке к конкретным
инструментам. Абсолютный минимум теории (чтобы было интересно тем, кто
не знаком со scrum).

В ходе доклада будет рассказано об успешном опыте (с реальными
примерами и скриншотами) реализации:
- scrum-доски (Jira)
- инструментов для ведения и поддержки в актуальном состоянии
технической и пользовательской документации (Confluence)
- польза и порядок организации гибридных (асинхронная часть +
синхронная) стэндапов (Geekbot.io, Skype)
- организация коммуникаций территориально распределенной (6 часовых
поясов) команды (Slack)
- организация сервис-деск с нуля за один день (Zendesk, osTiket)

По итогам доклада слушатели получат ответы на наиболее
распространённые вопросы, связанные с началом применения scrum:
1. С чего начать и какие инструменты использовать?
2. Как можно получить, и, тем более, запустить в опытную эксплуатацию
какой-то отдельный модуль по итогам спринта, если мы внедряем, к
примеру, бухгалтерскую подсистему, и там всё взаимосвязано?
3. Как убедить заказчика использовать scrum?

+ Потребность в дополнительном инструментарии помимо 1С-Конфигуратора, 1С-Предприятие
+ Краткий перечень полезных инструментов с обозначением решаемых задач
+ Показ практического применения инструментов для Конфигуратора
+ мощнейшие скрипты Снегопата для последней редакции 1С 8.3.10.2299
+ Показ практического применения инструментов в режиме 1С-Предприятие
+ "Портативные инструменты разработчика" для анализа/редактирования данных
+ подготовка тестовых данных/фикстур для инструментов тестирования/проверки поведения - xUnitFor1C, vanessa-behavior
+ Показ практического применения инструментов-автоматизаторов рутинных действий
+ мощные возможности автозапуска инструментов из командной строки при помощи скриптов OneScript (на языке 1С)

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

В управлении ИТ проектами – автоматизация, постановка учета, реинжиниринг, руководитель ИТ проекта или ИТ директор часто оказываются в ситуации, когда у них есть формальные полномочия, но нет фактических.
•    Как в этом случае действовать?
•    Как достучаться до того, кто выше по должности?
•    Как договариваться, когда полномочия на бумаге?
•    Что делать, когда на стороне клиента (внешнего и внутреннего) нет согласия по поводу проекта? «Лебедь, рак и щука».

Например:
•    В проекте по внедрению 1С участвуют сотрудники финансового департамента, которые формально должны  подчиняться руководителю проекта. А по факту они игнорируют его задачи, ссылаются на занятость.
•    ИТ директор часто находится в сервисной, обслуживающей роли в компании, при этом руководство ожидает от него инициативу в области оптимизации бизнес процессов. Однако, как только он проявляет инициативу и, например, предлагает варианты улучшения коммерческих процессов в компании, то слышит в свой адрес: «а чего это вы в продажи лезете, мы без вас разберемся».
•    Руководители проектов со стороны заказчика оказываются в ситуации, когда заказчик не соблюдает границы проекта – «7 пятниц на неделе». Но у заказчика есть финансовый рычаг давления, и он манипулирует этим, принуждая подрядчика идти на уступки.

Содержание доклада
1. Основные причины разногласий в проектах. Статистика на основе более 500 проектных кейсов с авторского тренинга для руководителей 1С проектов.
2. Официальные полномочия и фактическое влияние. Чем они отличаются?
3. Как повысить свой уровень фактического влияния, когда нет полномочий
4. Детальный разбор кейса с ситуацией по внедрении 1С в компании крупного холдинга
5. Ответы на вопросы участников конференции.

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

Вечерний мастер класс по решению кейсов участников, после завершения докладов.

- Уровень отказоустойчивости, какой выбрать в каком случае?
- Центральный сервер vs Рабочий сервер, в чём разница?
- Требования назначений функциональности, как это готовить?
- Настройки кластера и сервера 1С, какая на что влияет?
- Настройка инфраструктуры с сервером программного лицензирования 1С

Наш опыт внедрения RedMine в группе компаний 450+ сотрудников со штатом IT-управления 20+ специалистов, для организации работы service-desk, поддержки сервисной модели, управления проектами и руководства IT в целом.
RedMine - "тяжелый" выбор для "легкого" будущего! Почему не стоит бояться opensource-систем.

Как мы с помощью RedMine небольшими, но регулярными шагами продвигались к передовым методологиям разработки и внедрения IT.

Способы  интеграции Redmine с 1С, Outlook, еще чем-нибудь полезным.

Доклад будет полезен руководителям ИТ-подразделений крупных и средних компаний (до1500 человек), которые рассматривают инструменты автоматизации работы ИТ-подразделений, ищут пути оптимизации штата, ФОТа, сокращения внутренних издержек.

Будут рассмотрены:
1.    Показатели эффективности работы ИТ-подразделений компании в условиях отраслевой специфики.
2.    Инструменты повышения эффективности работы ИТ подразделения.
3.    Примеры внедрения  на практике и демонстрация результатов в части:
  a.    времени обработки запросов
  b.    распределения задач
  c.    групп ответственности
  d.    оцифровке нормативов
  e.    систем мотивации
4.    Интеграция между инструментами.

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

1. Введение.
Зачем нужны планы обмена, какую задачу они решают.
2. Структуры данных.
     1. Таблица плана обмена.
     2. Таблицы регистрации изменений.
     3. Индексы.
3. Механизм регистрации изменений.
     1. Момент выполнения автоматической регистрации изменений.
     2. Регистрация изменений программно, анализ T-SQL кода.
     3. Просмотр зарегистрированных изменений.
     4. Удаление изменений программно, анализ T-SQL кода.
4. Механизм обмена сообщениями.
     1. Запись изменений в сообщение обмена, анализ блокировок.
     2. Чтение сообщений обмена.
5. Основные проблемы планов обмена и методы их решения.
     1. Вызов метода "ВыбратьИзменения", конфликты блокировок.
     2. Решение проблемы блокировок при регистрации изменений.
     3. Рассинхронизация данных при обмене.
Например, документы приходят без движений и наоборот.
     4. Решение проблемы рассинхронизации, репликация транзакций.

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

1.Типовые подходы к оптимизации (по учебнику): поиск узких мест, оптимизация запросов, алгоритмов с транзакциями. Либо наращивание оборудования, чтобы в пиковый час "ничего не висело" и бизнес не терял деньги на заказах.

2.Альтернативный подход: перенос операций на другое время или выполнение в фоновом задании (в отдельном потоке)

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

1. Архитектура решения. Что нового?
2. Цели, этапы, периметр, особенности проекта
    a. Проектирование, Разработка, ПМИ, ОПЭ
3. Результаты
    a. Нагрузочное тестирование
    b. Сценарное тестирование
    c. Запуск Шины и подключение продуктивных ИС
4. Документация
    a. Cостав, Особенности подготовки
5. Выводы, Тиражирование, Перспективы…

Взгляд на вопрос глазами профессионального работодателя.
Когда и каким образом проводить переговоры о повышении зарплаты с текущим работодателем? Как эффективнее и безопаснее искать новое место работы? Важность соцсетей, портфолио и "рекомендателей».
Регулярное формирование личного бренда и персональный контент-маркетинг. Блоги, статьи, видео, доклады на мероприятиях – что именно, где, когда и как правильно делать? Живые «кейсы» (примеры).
Примерный порядок мастер-класса (тезисы).

1. Почему возникла необходимость в инструменте типа “RedMine”
2. Почему именно RedMine среди других продуктов
3. Исходные критерии и основные возможности RedMine или “Аппетит приходит во время еды”
4. Небольшими шагами от Service Desk к сервисной модели управления
5. Организация механизмов управления проектами
6. Формирование конечной цели: Руководство IT-отделом
7. Планы на будущее
8. Ожидание и реальность.
9. RedMine не только для ИТ

Как только разработчиков становится больше двух, сразу возникает вопрос "А кто же будет ими управлять"
Для кого доклад: для менеджеров, которым нужны заместители, для разработчиков, которых хотят поруководить

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

А так что не надо делать :) На основании личного опыта

Основные темы:
- Как определить сможет ли разработчик быть менеджером
- В какой момент пора готовить себе замену
- Чем руководитель отдела разработки отличается от руководителя любого другого отдела
- Должен ли руководитель разработки быть программистом
- Внутренний маркетинг - зачем и как хвалить себя
- И вот вы менеджер - что делать
- Практические советы

В докладе хочу поделиться своим опытом применения платформы "1С:Предприятие 8" в качестве полноценного backend-стека при разработки web-приложений. На наглядных примерах (мини-интернет магазин) продемонстрирую как при помощи "1С:Предприятия 8", технологии HTTP-сервисов и популярного стека технологий фронтенд-разработки (HTML/CSS/JavaScript) можно создавать полноценные web-приложения. Доклад будет строится на рассмотрении реального приложения типа мини интернет-магазин. Из моего доклада читатели узнают:

- Какие бывают web-приложения;
- Возможности HTTP-сервисы, которые выходят за рамки документации;
- Как подружить фронтенд (HTML/CSS/JS) и бекенд (1С:Предприятие 8);
- Чем отличается серверный рендеринг от клиентского;
- Объясню зачем современному 1С-разработчику может потребоваться JavaScript;
- Рассмотрю другие практические кейсы применения HTTP-сервисов;
- Затрону тему ограничений, связанных с разработкой web-приложений;
- На примерах продемонстрирую технику разработки и отладки HTTP-сервисов при помощи дополнительных инструментов;

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

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

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

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

Ну и главное - как объяснить программистам 1С, зачем им нужно работать втрое быстрее за те же деньги :)

Доклад основан на реальном примере, реальной команде, с реальными цифрами.

В отчетном докладе будет рассказано о жизни проекта «Первая Международная Типовая» за период с прошлого Инфостарт Ивент’а: об успехах и неудачах; о проблемах и решениях; о достижениях и недоработках; о том, что уже сделано и что еще предстоит сделать. Будет рассказано о том, как работает самая распределённая команда разработки в истории «1С»; о том, как преодолеваются противоречия, непреодолимые на первый взгляд; о том как одноязычные инструменты превращаются в мультиязычные.
И самое главное – про то, что рынки дальнего зарубежья ждут своих героев.

Механизмы 1С для групповой разработки и адаптации типовых прикладных решений на проекте
Практический кейс по организации одновременного использования хранилища и расширений 1С в проектной группе из 10 разработчиков.
1. Плюсы и минусы хранилища и расширения
2. Возможные варианты использования хранилища и расширений
3. Переход от расширения к хранилищу или к хранилищу + расширение

    Не секрет, что зачастую руководство компании, собственники бизнеса ждут от внедрения ИТ систем "прорыва" - сокращения издержек на персонал, автоматизации процессов, контроля за бизнесом онлайн. Однако многие компании, перейдя на использование новых информационных систем, получают все то же самое что и было до внедрения, только в "автоматизированном" варианте. Дополнительно  вместо "простых" бухгалтеров надо содержать более квалифицированный персонал, который сможет грамотно провести закрытие периода в 1С или даже сформировать баланс и отчет по налогу на прибыль в SAP. Да еще и затраты на программистов, сервера, службу поддержки и т.д. А где же прямая экономическая выгода? А выгода становится очевидной, когда количество и охват бизнес-процессов различными ИС превышает критическое значение, что позволяет полностью перестраивать бизнес-процессы, переводя их в "цифровой" формат. В ходе доклада мы поговорим о том, как имея стандартный набор систем на базе 1С приблизиться к реализации концепции Industry 4.0, повысить эффективность бизнеса и доказать менеджменту что вложения в ИТ - это крайне выгодно.
    Мы обсудим вопросы, ответы на которые помогут в работе любому ИТ руководителю:
    1. Почему классические информационные системы типа автоматизации бухучета, перевода процессов с бумаги в электронный вид далеко не всегда увеличивают эффективность компании?
    2. Как перейти от разрозненных автоматизированных в различных информационных системах бизнес-процессов отдельных подразделений к комплексному взгляду на бизнес-процессы компании?
    3. Как имея стандартный набор конфигураций 1С на предприятии повысить экономическую отдачу от их использования без внесения значительных доработок, внедрения новых подсистем? Практические примеры.
    4. Что такое концепция Industry 4.0? Почему рано или поздно к этому придут все предприятия?
    5. Как оценить потенциальный экономический эффект от перевода бизнес-процессов в полностью "цифровой" формат? Практические примеры.

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

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

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

План выступления:
1. Вступление
2. Полезные скрипты SQL
    a. Задания SQL Server
3. Инструменты автоматизации
    a. BAT-файлы
    b. VBScript
    c. xStarter
    d. Конфигурация 1С
    e. OneScript
4. Стандартные библиотеки OneScript
5. Совмещаем bat + OneScript + SQL
6. Программы и скрипты для автоматизации рутинных действий
    a. «Перезаливатор», «Обновлятор» и др.
7. Регламентные задания на серверах клиентов
8. Контроль выполнения регламентных заданий
    a. Конфигурация «СОК»
9. Заключение
10. Материалы, ссылки

Решаемая задача: создание на сайте предприятия Личного кабинета абонента Водоканала с функциями :
- быстрая регистрация (достаточно указать только мобильный телефон) для абсолютно любых граждан;
- приём заявок и вопросов в электронной форме от абонентов (или граждан);
-  отработка заявок, вопросов сотрудниками предприятия;
-  управление абонентами своими лицевыми счетами (просмотр информации о состоянии, передача показаний, онлайн оплаты, вызов контролеров)

Этапы создания системы:
- Выбор архитектуры системы: Битрикс, 1С http-запросы, Odata, web-сервисы, БСП;
- Что «отдать» Битриксу, а что делать в 1С? Какие программисты понадобились;
- Создание в 1С http и soap шлюзов с базами 1С для работы с Битриксом или  как бороться с ситуацией, когда все отделы автоматизированы, но ни единой учетной системы ни целостной картины нет;
- Используем запросы Odata по «полной» (чтение и внесение данных в базу), настройка кэша соединений;
- Как по-другому взглянуть на  подсистему БСП «Анкетирование»  (универсальный механизм создания и отображение Битриксом сложных заявок (прикрепление файлов, выпадающие списки и т.п.) различных видов без ограничений по количеству);
- Интернет-платежи (эквайринг): быстро и удобно. На что обратить внимание;
- Прикручиваем другие подсистемы БСП: уведомление, sms-рассылки, email – рассылки, хранение файлов, пользователи, версионирование, небольшое управление через Telegram (спасибо Infostart и автору разработки);
- Адаптивный дизайн или  точно ли нужно мобильное приложение?
- Демонстрация как всё это работает «в живую»

Дальнейшие планы (до ноября 2017 г.):
- Выкладка электронных подписанных документов в 1С:Бухгалтерии в кабинет потребителя для юридических лиц и предпринимателей.
- Отдельное мобильное приложение;
- Электронная подпись на сайте для небухгалтерских документов, чтобы вообще не нужно было ходить «ногами» для заключения договора и т.п.
- Аутентификация через сайт  гос.услуг.
- Онлайн-кассы за кабинетом (54-ФЗ)

Система проектирования прикладных решений (СППР) - продукт, позиционируемый 1С для для проектирования прикладных решений (конфигураций) на платформе «1С:Предприятие» и ведения технической документации проекта. Однако, разработка под конкретного заказчика, когда отдел работает внутри компании, имеет свои особенности. Целью доклада является обзор опыта применения СППР для управления отделом. Будут освещены сильные стороны СППР и моменты, которые пришлось улучшать.

В ходе доклада поговорим о следующем:
* Особенности разработки для внутреннего заказчика
* Жизненный цикл задачи
* Вид работ отдела разработки: разработка, тестирование, документирование, сбор и формализация требований
* Управленческие подходы к планированию работ отдела разработки
* Как можно планировать с помощью СППР, и чего не хватало
* Оперативное управление задачами в отделе разработки
* Как организовать учет фактических трудозатрат, что бы не усложнять при этом работу
* План-факт анализ работ и трудозатрат: когда смотрим сколько сделано, а когда что делали
* Контроль доставки результатов до заказчиков
* Разбор полетов: "зачем это сделано"
* Итоги эксплуатации СППР для нашего отдела

- Столбцовые СУБД. Что это такое и для чего они нужны.
- Если в таблице менее 100 млн. записей - она маленькая, достаточно средств MS SQL (сжатие, секционирование)
- Yandex ClickHouse - самая (ну или почти самая) быстрая СУБД в мире.
- Что может и чего не может ClickHouse.
- Какие задачи решает и какие позволяет решить.
- Установка и настройка.
- Использование совместно с 1С.

Гибкие методики управления программными проектами достаточно широко вошли в нашу жизнь и доказали свою жизнеспособность, увеличив процент успешных проектов от малых до крупных. Однако, внедряются эти методики достаточно сложно. Основная причина – это конфликт между желанием фиксировать стоимость и сроки проекта и возможностью сделать это в момент минимальной определенности содержания проекта. По сути, это конфликт между «Когда? Сколько?» и «Что?» или, другими словами, конфликт между моделями оценки «Fixed price» («FP» - фиксированная цена за проект под ключ) и «Time & Material» («T&M» - оплата за результат, исходя из затрат). Модель «T&M», как правило, пугает заказчиков «А вдруг мне сделают дороже?», модель «FP» рискованна для исполнителей «Или потеряю клиента, назвав цену с учетом рисков, или потеряю репутацию, когда бюджет закончится, а работа останется!».
Усилия, направляемые проектными группами на совершенствование методов оценки, теряют экономический и практический смысл - чаще легче сделать и измерить (T&M), чем оценить (FP) и уложиться. Хотя, если присмотреться, метод T&M – это тот же FP, только на меньшем промежутке времени – принципиальные отличия отсутствуют. В одном случае (FP) фиксируется стоимость проекта целиком за весь срок, в другом случае (T&M) фиксируется стоимость одной итерации. Может показаться, что метод T&M способен исключить ошибки в оценке и увеличить процент успешных проектов, но статистика программных проектов говорит об обратном.  Более 80% выходят за рамки ограничений сроков и стоимости. Что же делать?
Возникает мысль, если оценки столь ошибочны вне зависимости от выбранного метода, может быть совсем отказаться от оценки? При всей парадоксальности этой идеи, она нашла свое развитие. Несколько лет назад за рубежом появилось целое направление в оценке программных проектов с громким названием #NoEstimates («#БезОценок»). Спрашивается, как в таком случае управлять стоимостью проекта?
В докладе расскажу о собственном понимании принципов «#NoEstimates» и об опыте работы «#БезОценок» - как применить эти принципы для увеличения количества успешных проектов.

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

- Сравним существующие решений: плюсы и минусы, на чем остановились;
- Про сценарные тесты: наш опыт создания, особенности и подходы, библиотека сценариев, обработка "менеджер сценарного теста";
- Про юнит тесты: наш опыт создания и использования, проблемы и решения;
- Расскажем об интеграция с GIT, командной разработке;
- Как мы все это смотрим и запускаем - кастомная конфигурация "Тестирование 3.0": планировщик заданий, просмотр результатов тестов, "allure skin", "jenkins skin";
- Рассмотрим интеллектуальные тесты, игровое моделирование сценарных тестов;
- Обрисуем инфраструктуру: наш опыт, ночной билд, релизная сборка.

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

Описание проекта по внедрению системы мотивации в ИТ-службе:
- Предпосылки внедрения системы мотивации (как мы шли к этому, почему нельзя было оставить все как есть)
- Трудозатраты или деньги? (Что важнее видеть сотруднику при получении задания?)
- Алгоритм определения выработки сотрудника.
- Методика расчета выплаты сотруднику нарастающим итогом (повышение ответственности сотрудника за выполненную работу, аналог "гарантийных" обязательств)
- Автоматизация процесса выдачи заданий, контроль исполнения, расчет выработки (использование Redmine, 1С)
- Итоги "в цифрах" (чего добились после внедрения данной системы мотивации, как изменилось качество сдаваемых работ заказчику, как изменились доходы сотрудников при незначительных изменениях базовой части оклада).

Общие положения
Что, зачем, в чем выгода использования СУБД на предприятиях любого размера.

Схема инфраструктуры
Использование виртуализации и кластеров гипервизоров, естественно тоже opensource.

Рабочие серверы
Тонкий тюнинг

Сервисы администратора
сбор и анализ журналов (штатные Linux инструменты, специализированные инструменты 1с, специализированные инструменты Postgres)
    
Бэкапы
pgbarman + PostgreSQL Backup

Мониторинг
Zabbix: мониторинг сервера 1с, мониторинг сервера PostgreSQL

Проблемы
Некоторым инсталляциям показан сервер 1с на Windows

Как сделать так чтобы с разработчиком хотели работать всей душой?
Я расскажу выводы из 5-летней истории развития soft-skills в сотрудниках.

1. Почему нетехнические навыки важны?
2. Какие есть нетехнические навыки и как их развивать?
3. Основные правила взаимодействия с коллегами и клиентами.
4. Проблемы при взаимодействии и как их решать.
5. Как быстро построить доверительные отношения?
6. Пример системы развития нетехнических навыков в компании.
7. Культура обратной связи и непрерывного развития.