Виды публичных и частных облаков Microsoft
Преимущества и специфика перехода в облака
Возможные сценарии использования облака для «1С:Предприятие»
Облака Microsoft и мобильные платформы

• Что такое быстрое закрытие?
• Какие функции должна иметь информационная система для обеспечения быстрого закрытия?
• Какие функции для обеспечения быстрого закрытия есть в 1С: Управление холдингом?

История создания сервиса - нужны ли инвестиции?
Как устроена облачная компания
Что ждут от облаков пользователи
Конкурирует ли МойСклад с продуктами 1С?

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

1) Введение. Тренд: веб приложения, мобильный веб, гибридные мобильные приложения.
2) Веб приложения всегда состоят минимум из клиентской и серверной частей. Разработать, развернуть инфраструктуру, настроить различные обмены данными - это не быстрый процесс. А нужно ли приложение в таком виде? Принесет ли оно пользу заказчику? Как не потратить время и ресурсы зря? Выход - очень быстро сделать и показать заказчику работающий прототип приложения! И, если что-то не устраивает, также быстро доработать или вообще создать новый прототип. А уже после утверждения и получения положительного отзыва от заказчика, разрабатывать полноценную продакшн версию системы с использованием надежных инфраструктуры, технологий и подходов.
3) Живой пример быстрого создания прототипа приложения.

Большинство из нас привыкло полагаться на стандартизованные, хорошо формализованные процессы разработки ПО. Эти процессы отлично спроектированы, проверены временем, они работают. Да, есть определенные проблемы, например, на выходе проекта заказчик не всегда получает то, что ему на самом деле нужно. Но любой стандартный процесс умеет с этим справляться - через процедуру change management, мы просто предлагаем заказчику доделать продукт так, как ему теперь нужно, правда, за дополнительные бюджет и время.
С другой стороны, динамика изменений со стороны бизнеса сейчас настолько велика, что впереди оказываются компании, процесс разработки в которых непрерывно эволюционирует. Эволюционный процесс позволяет научиться делать более быстрые поставки, более качественные решения, а главное, поставлять с первого раза именно то, что нужно бизнесу.
Необходимый минимум для этого - 4 основных точки улучшения стандартного процесса, которые мы рассмотрим во время этого доклада.

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

Внедрение методологии Scrum "снизу" - как мы начинали и как получали одобрение начальства.
Инструменты и принципы методологии:
- непривычные стэндапы;
- доска, или как управлять миром при помощи стикеров;
- планирование и ретроспектива.
Особенности оценки - как мы переводили story points в часы и зачем.
Развитие, или причем тут Kanban.

- Управляемый переход на новую версию БД MS SQL
- Эффективный выбор аппаратных и программных ресурсов для сервера БД
- Миграция в облако

Почему SAP это SAP (причина популярности).
Матрица покрытия функциональных модулей ERP и SAP.
Интерфейс пользователя.
Как совершенство SAP "разбивается" о несовершенство Российского учета.
О тяжелой жизни простого ABAP разработчика.
Подходы к внедрению. Формирование стоимости решения.
Тенденция развития

Всегда ли клиент знает, какие права необходимы его сотрудникам в учетной системе?
Как часто интегратору приходится самостоятельно принимать решение о предоставлении прав пользователям?
Свобода пользователей в продуктовой и не продуктовой рознице.
Что может администратор на стойке регистрации?
Гибкие скидки в продажах – как построить систему, чтобы предусмотреть всё.
Производственное предприятие – есть ли защита от изобретательного дурака? Разбор случаев сознательного искажения учета и саботажа.
Обучение внутреннее и внешнее

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

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

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

У нас есть опыт оптимизации и контроля производительности высоконагруженных баз данных (более чем 3000 одновременно работающих пользователей, > 800 000 документов/день, ~2Тб данных).
Можем ей поделиться, в частности:
- используемые инструменты для мониторинга системы;
- используемые инструменты для поиска узких мест;
- архитектурные ошибки и советы разработчикам;
- подход к контролю кода перед обновлением конфигурации;
- разделение системы на OLAP и OLTP средствами планов обмена.
Также принимали активное участие в проекте перехода на 8.2, этап тестирования описан тут: http://v8.1c.ru/news/newsAbout.jsp?id=10915
Готов рассказать, почему именно ЦКТП, какие трудности были в процессе проекта, какой эффект производительности получили на реальной системе.

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

1. Нагрузочное тестирование 1С на 5000 пользователей в одной базе
2. Технологические проблемы, возникающие при одновременной работе большого количества пользователей (несколько тысяч)
3. Совместная работа с фирмой "1С" в рамках проектов ЦКТП на примере проекта http://v8.1c.ru/expert/cts/cts-218-001.htm

Доступные виды обучения
Достоинства различных видов обучения
Практика - основа результативного обучения
Интерактивное обучение - знания и практические навыки для всех!

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

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

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

Опыт ВЦ «Раздолье» по внедрения систем управления на базе программ «1С».
Самый востребованный клиентами функционал 1С:ERP.
Возможности оперативного управления производством в 1С:ERP. Опыт первого проекта.
Опыт подготовки специалистов к внедрению 1С:ERP. Новая программа - проблема или возможность для интегратора?
Плюсы и минусы 1С:ERP.
Стоит ли внедрять 1С:ERP?
Специфика проектов внедрения.
Опыт реальных проектов внедрения 1С:ERP.

Проблема оценки ИТ-проектов актуальна столько времени, сколько существуют ИТ-проекты. За это время неоднократно появлялись новые подходы, со своими достоинствами и недостатками. В настоящее время до сих пор не существует «серебряной пули», защищающей от ошибок в оценке. Однако есть практика использования различных подходов, анализ которой поможет выбрать для себя те пути, которые ведут к наименьшим рискам.
В докладе будут рассмотрены:
- Практика оценки ИТ-Проектов
- Методы оценки
- Типичные ошибки при оценке проектов
- Оценка рисков на практике

1. Чем занимаемся (предмет доклада, описание деятельности)
2. История деятельности (кол-во проектов, сотрудников – динамика по кварталам. Показываем, как была устроена деятельность, какие коррективы вносились и к чему это привело)
3. Как устроена и как функционирует деятельность сейчас (структура деятельности, принципы и правила управления)
4. Отделы, подразделения в компании (схема)
5. Планирование, распределение задач (схема, какой отдел за что отвечает)
6. Ключевые показатели деятельности (графики, схемы, статистика, примеры)
7. Ключевые ошибки, трудности (статистика, примеры)
8. Выводы и планы развития (решение трудностей, принципы дальнейшего развития)

a.       Разработка через документирование.  
            i.      Сначала документация – потом реализация.
            ii.      Формализация и согласование требований к документации с Заказчиком
b.      Документирование – это не только Руководство пользователя!
c.       Опыт интеграции объектов разработки, задач на разработку (тех. заданий) и пользовательской документации
d.      Возможности новой редакции продукта «2iS:Интеграция» и опыт использования продукта за последний год
            i.      Конвертация данных из любых внешних источников с использованием обычных правил обмена
            ii.      Шина веб-сервисов для любых конфигураций 1С, без их изменения
            iii.      Опыт централизованного управления пользователями в базах 1С
            iv.      Подсистема Веб-портал отчетности, для любых инфобаз 1С

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

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

- Скрипты автоматизации и администрирования на языке 1С, в том числе под Linux
- Консольные приложения на языке 1С
- Расширение Снегопата с помощью OneScript
- Веб-сайт на языке 1С.

1. Непрерывная интеграция функционала. Методическая практика развертыванияпродукта. Блоки работ необходимые к проведению в рамках передачи релиза конфигурации в production эксплуатацию. Методические рекомендации фирмы 1С по подготовке продукта к непрерывной интеграции.
2. Способы реализации этапов непрерывной интеграции функционала на платформе 1С и сервере непрерывной интеграции Jenkins.
3. Особенности прохождения этапов сборки и развертывания в зависимости от типа задачи - исправление ошибок, изменение кода, изменение структуры метаданных и т.д.
4. Типовые недочеты и способы их исправления в рамках автоматизированной сборки продукта и его последующего развертывания. Типовые сценарии отката развернутой функциональности.

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

·        Особенности проектов автоматизации МСФО;
·        Процесс перехода компании на самостоятельную подготовку отчетности по МСФО;
·        Схема и особенности взаимодействия Консультанта и Интегратора на проекте;
·        Заключение и выводы.

Что вызывает больше всего проблем в эксплуатации, и чему почти не уделяют внимания?
Объекты контроля: аналитика и процессы, или Как выделить главное
Механизмы контроля
Регламенты контроля в составе проектной документации
Кейс «ТЗ стандартные ошибки»