Infostart journal 2

INFOSTART JOURNAL №2 Ноябрь 2013 Сборник докладов II всероссийской профессиональной конференции Infostart Event Evolution 2013 (23-24 мая 2013 г.) «Управление и технологии автоматизации учета на платформе 1С:Предприятие».

ООО «Инфостарт» Санкт-Петербург, 2013

Здравствуйте, коллеги! Представляю вашему вниманию второй номер журнала Infostart Journal. Журнал представляет из себя дайджест выступлений докладчиков на второй конференции Infostart Event Evolution 2013. Много интересного и полезного материала. Вообще, идея выпуска своего журнала была у нас давно. Еще в 2007 году многие из вас писали мне, что было бы здорово почитать материалы с сайта, собранные воедино в печатном издании. Я всегда отвечал, что весь наш сайт и есть журнал, только электронный, а печатные издания ждет неминуемая гибель. Наступила эра электронных книг и планшетов, мир стремительно отказывается от периодики, «Вашингтон пост” вводит платную электронную подписку. А мы возвращаемся к истокам. Наш журнал - это больше подарок, приятный артефакт для наших участников. Ограниченный тираж тому доказательство, что дает полное право присвоить ему статус раритета. ;) Поэтому мы не планируем выпускать такой журнал часто, весь интересный и свежий материал всегда будет на нашем сайте. Если задуматься, то это же фантастично, когда ктото захотел поделиться своим опытом с коллегами, опубликовал статью или программу, и в этот же момент тысячи коллег уже изучают и критикуют, подбадривают или журят, советуют и комментируют. Притом это именно «коллеги по цеху», которые либо уже сталкивались с подобной задачей, или им это еще только предстоит. Именно в этом заключается магия Интернет-сообщества, которая объединяет и двигает нашу индустрию вперед. Обмен опытом, быстрая обратная связь, независимая оценка, не всегда объективная, но в этом и ее плюс. Все это в совокупности дает возможность сделать, так сказать, “разведку боем” любого решения. Когда на сайте появляются действительно интересные и уникальные решения, реакция Сообщества незамедлительна: рейтинг публикации растет очень быстро. У нас рождаются свои “звезды”, которых мы с удовольствием приглашаем выступить на нашей конференции. Поэтому на страницах этого дайджеста вы найдете доклады “лучших из лучших” участников Сообщества, а также приглашенных заслуженных экспертов нашей отрасли. Увлекательного чтения! С уважением, Цыденов Доржи

–3–

Содержание Сергей Коцюра Практические вопросы внедрения и развития автоматизации склада.......................................................6 Андрей Гилев Приемы повышения производительности 1С...................................................................................................... 13 Сергей Старых Повышение эффективности разработки на платформе 1С с помощью подсистемы «Инструменты разработчика» (кратко об основных инструментах и наиболее эффективных приемах их использования)................................................................................... 21 Фарит Насипов Кейсы как инструменты работы с клиентами......................................................................................... 30 Сергей Яковенко Практические приемы организации службы поддержки в условиях постоянных изменений....... 39 Александр Тарасинский Кейсы проектов как инструмент успешного запуска автоматизированных систем............................. 47 Михаил Харитонов Практика централизации управления информационными базами и интеграционными процессами............................................................................................................................... 55 Евгений Шумилов Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования.............................................................. 66 Евгений Сосна Альтернативные системы контроля версий и практика применения с 1С............................................... 78 Андрей Аристархов Новые возможности платформы «1С:Предприятие 8.3»................................................................................. 87 Федор Куликов Построение информационной системы современного предприятия на базе СПО (свободного программного обеспечения)...........................................................................................................107 Андрей Акулов Когда сотрудник становится гаджетом..................................................................................................................114 Сергей Лебедев Подходы к управлению проектной организацией...........................................................................................125 Артур Абеленцев Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде............137 Алексей Патюков Организация жесткого контроля при внедрении информационных систем........................................147 Франц Бдоян ИТ duediligence: как ИТ-служба может повысить стоимость компании..................................................153 Павел Чистов Я аттестованный специалист, или Без бумажки ты букашка!.......................................................................158 Дмитрий Шерстобитов Мобильная платформа 1С: какие сложности вас ждут и как их обойти.................................................165

Практические вопросы внедрения и развития автоматизации склада Сергей Коцюра Руководитель IT-отдела торговой компании. 13 лет в сфере 1С – от теории и программирования до практических вопросов работы персонала

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

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

Интересно узнать, в зале много людей, которые в 2006 году на Инфостарте зарегистрировались? Да, можно сказать, что таковые люди в зале отсутствуют...

Понятно, что регистрация тривиальная, это и тогда не выглядело чем-то новым или чем-то похожим на что-то серьезное… Но, тем не менее, заявка была сделана. К тому времени свое место в сфере 1С у меня уже было. С работодателями проблем не было, денежно более-менее был обеспечен, работа шла по накатанной колее. Даже немножко уже скучно было... Поэтому я подумал – почему бы во всем этом не поучаствовать? Хуже от этого не будет...

Буквально сразу же Инфостарт задал достаточно высокую планку. Это можно видеть по текстовке следующего письма от Инфостарта:

Строки «На Вашем счету несколько успешных внедрений автоматизации учета» дали мне понять, что за мной явно следили, потому что я не особо распространялся о своих успехах ;-)

Но больше всего меня порадовало утверждение «Ваш IQ превышает 150 пунктов». Последний раз я свой IQ считал ради хохмы где-то в 2000 году – тогда он был где-то в районе 112-124 (точнее не скажу за давностью лет). А за шесть-семь лет общения с 1С совершенно четко понятно, что мой IQ не стоял на месте, он не мог не вырасти, он – безусловно вырос... ;-) То есть, после прочтения этого письма, во мне поселилась уверенность, что я однозначно в это сообщество войду! Тут еще в кулуарах, перед началом конференции, подсказали, что значение IQ одинэсника в альтернативных единицах измерения – 146%. То есть, уже в самом начале конференции можно констатировать, что получен конкретный практический результат конференции – определено соотношения таких единиц как “пункты” и “проценты”.

–6–

Сергей Коцюра

Практические вопросы внедрения и развития автоматизации склада

Возвращаясь к теме Инфостарта: – почему это было интересно? Как я уже сказал, в принципе, все у меня уже более-менее устаканилось. Поэтому хотелось чего-то нового, хотелось что-то дать обществу – просто так. В то время Инфостарт вел активнейшую маркетинговую политику. В то далекое время финансовые потоки шли от Инфостарта наружу пользователям – проводились розыгрыши призов, для участия в розыгрыше необходимо было, чтобы выставленная в каталог программа набрала рейтинг не меньше трех (да, это был очень высокий показатель в то время! ;-). И я своему киндеру, который тогда учился где-то в средних классах школы, сказал: «Это – интересно! Я точно чтото выиграю!». Открывавшиеся возможности я прежде всего рассматривал как возможности общения и участия в большой группе людей – это было для меня всегда интересно. По этому поводу была разработана определенная методика, произведен массовый «вброс» на Инфостарт материалов и, как вы видите, приз я тогда все-таки успешно выиграл.

Здесь вы видите первого призера Инфостарта – разработчика под ником Wolfy. Ну и я рядом – радостно на Почте России стою с полученным КПК HP Invent.

Впоследствии наполнение каталога Инфостарта пошло достаточно активно. Много всего интересного было. Смена интерфейсов, дизайна, подходов… Это была очень интересная пора – это была пора «бессребреников Инфостарта». Особой популярностью пользовались всякие перенумераторы, доводившиеся до совершенства ;-), вовсю автоматизировалась “торговля шпингалетами” (в связи с этим нельзя не упомянуть Олега, ник OPlanet) – это был один из самых основных участков применения автоматизации тогда ;-).

Активная работа по наполнению Инфостарта не прошла даром – те, кто в 2006 году начал наполнять каталог, до сих пор в первых рядах рейтинга разработчиков Инфостарта (Топ-100). О чем это говорит? «Кто первым встал – того и тапки». То есть, первыми встали – заработали авторитет, схватили нишу... И вот эти позиции – они дают определенный «профит», в том числе и при разговорах с людьми/заказчиками, которые обращаются: «Нашли тебя на Инфостарте, не поможешь?» И при разговоре с директорами и управленцами, когда на тебя пытаются давить или «прижимать», можно спокойно сказать «Коллеги, я достаточно

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

Однако, время не стоит на месте, парадигма Инфостарта к данному моменту поменялась… Но, как оказалось, Инфостарт успешно развивался, пережил все кризисы, и, в итоге, сейчас большое количество народа собралось в этом зале. Бессребреники и «торговля шпингалетами» как массовое явление уже ушли в прошлое, сейчас актуальны «эпоха КАМАЗов» и «алчный» Орефков ;-).

Я нисколько не жалею того, достаточно большого, затраченного и отданного Инфостарту, времени… Я думаю, никто из тех, кто регистрировался в начале развития Инфостарта, не жалеет о том, что мы вложили столько сил в создание такого сообщества, которое я с большим удовольствием вижу сейчас в зале. Здесь есть много труда большого количества людей, и меня греет, что в этом большом труде есть и частичка моего труда. И я рад тому, что в итоге Инфостарт превратился в ведущего игрока нашего сообщества. В том числе мы уже, видите – разрешаем и 1С выступать на своих конференциях ;-). То есть с нами считаются. И это радует. Это была вступительная часть, чтобы проснуться, взбодриться, разогреться.... Надеюсь, кто-то что-то интересное/занимательное для себя увидел.

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

Практические вопросы внедрения и развития автоматизации склада

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

Малые компании – это достаточно своеобразные фирмы. Некоторые из них изначально образовываются в количестве нескольких десятков человек. Некоторые – вырастают из простых «ларечников»,

–7–

INFOSTART JOURNAL №2 НОЯБРЬ 2013 «торбешников». Развитие сопровождается и ростом проблем, потому что, к сожалению, весь наш бизнес, зачастую, построен так, что «Давай сейчас! Надо рубить, думать некогда! Надо завтра, иначе будет поздно!» – и никто особо не задумывается о том, во что это выльется потом.

Фирмы растут. Потихоньку происходит развитие… И от какого-то цельного конгломерата фирма из 2-3 человек (когда все было более-менее понятно и просто) дорастает до нескольких десятков человек – образуются отделы, подотделы. Растет количество подразделений, растет количество связей... А о людях, которые бы эти связи удерживали вместе и не давали фирме «разлететься», к сожалению, думают в самую последнюю очередь...

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

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

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

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

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

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

Встает вопрос – так, всё! Мы сейчас автоматизируем склад, и у нас резко-резко (вот как на графике вертикально вверх) все сразу станет хорошо.

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

–8–

Сергей Коцюра

Практические вопросы внедрения и развития автоматизации склада

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

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

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

К сожалению, когда фирма растет, у собственников/руководства всегда есть какое-то свое видение о том, как их фирма будет развиваться. Но обычно это видение заключается в том, что «Давайте больше продаж, давайте деньги!» Ну, в принципе, это нормально. Ради этого бизнес и существует ;-) Однако, для того, чтобы сделать нормальный склад и, соответственно, сделать нормальное обслуживание клиентов и получать много-много денег – нужно считать.

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

фактами. Общие факты, общие размышления, общие суждения, интуиция – они могут существенно подвести. Поэтому – считать-считать-считать! Как правило, в малых компаниях людей, которые могут вот так считать-считать-считать – найти очень тяжело. Привлечь грамотного логиста (специалиста на рынке) тоже может не получиться. Руководство может тривиально душить жаба (это как всегда). Как оценить квалификацию такого специалиста? Да и свободных специалистов тоже не особо найти... Привлечь представителей каких-то больших WMS-систем для оказания консультаций (не для внедрения этой большой WMS-системы, а просто для оказания консультаций), тоже проблематично, потому что это, все-таки, узкоспециализированная область, люди на этом зарабатывают деньги. Они, как правило, продают проект целиком. Да и не готово руководство платить 300-500 тысяч консультантам. Просто не готово. Не осознали еще у нас такую необходимость...

Остается практически одно – надо опираться на собственные силы. Никто из приглашенных консультантов вам хороший склад не сделает. Никто не будет особо тратить тонны времени на то, чтобы разобраться во всех ваших деталях и во всех ваших особенностях. Поэтому – считайте сами. Начинайте считать со статистики. Со статистики товарооборота – коробок, штук, отгрузок, строк, приходов, площадей склада… Считайте всё, до чего вы можете дотянуться.

Потому что, к сожалению, наблюдается как: «Все, мы переезжаем на новый склад!» Переехали – и выясняется, что, в общем-то, по своим характеристикам этот склад совершенно не подходит, потому что он не учитывает особенности товаропотока, движения товара. Вообще, просто ситуацию не просчитали. Купили/арендовали помещение со стеллажами – вот и весь выбор склада. А в результате это приводит к немаленьким проблемам.

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

Привычки – это люди. Персонал – это просто какое-то больное место. «Успешность работы склада зависит не от автоматизированной системы. Она зависит от того, какие люди работают». Автоматиза-

–9–

INFOSTART JOURNAL №2 НОЯБРЬ 2013 бираем заявки, а потом слушаем шум дождя – отвечаю им я.

–Нет, мы сейчас отдохнем, а вот потом напряжемся и будем работать….

ция – это всего лишь помощь.

Зачастую на новый склад перевозят старый персонал. Где-то это проходит, где-то это не проходит.

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

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

С персоналом – беда! Инициативы мало, желания мало. Это ни хорошо, ни плохо – это так есть, это – жизнь. Естественно, все еще упирается в систему мотивации, которая при отсутствии четкого понимания, кто что делает и как работает склад, не сильно помогает. То есть все становится очень плохо. Работа превращается в нервотрепку и беготню.

Основная задача большой автоматизированной системы всего лишь одна (если брать по-крупному) – не дать персоналу сделать неправильно, не так, как должно быть. Проблемы в том, что персонал всегда делает так, как ему удобней – не так, как нужно для бизнеса, а так, как удобней персоналу, так, как проще для склада. Поэтому в первую очередь нужно работать над тем, чтобы изжить такую систему. Какими путями – это отдельный предмет обсуждения. Где-то для этого даже автоматизированной системы не надо.

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

Если говорить на моем примере – у меня это магистраль «Москва – Новорязанка» – из области в Москву. Это – капитальные пробки. Если машина не ушла до 7 часов утра со склада, можно считать, что поставки на данный день по Москве сорваны. Это сразу приводит к необходимости организации сменного режима работы, на каждую смену начальника склада не заведешь. Возникают проблемы с управлением персоналом. Соответственно, это все – стабильность, прогнозируемость работы склада и общий настрой. Приезжаю на склад утром, часиков в семь – барабанит дождь, заявки не собранные, утреннее звено складского персонала сидит на трубах стеллажей. Спрашиваю: –Что делаем?

–Слушаем шум дождя!

–Не вопрос, но только давайте так: сначала со-

– 10 –

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

Сергей Коцюра

Практические вопросы внедрения и развития автоматизации склада

есть свои особенности. Поэтому в первую очередь обращайте внимание на эти особенности.

• Отдельно хочу выделить позицию «начальника склада». Это мой личный опыт. Я бывал на разных складах, общался с начальниками складов. Старайтесь, чтобы начальник склада был максимально приближен к административно-управленческому персоналу фирмы. Как только у вас начальник склада начинает «сваливаться» больше в сторону склада – он начинает отстаивать интересы исключительно склада. Он начинает отстаивать свои личные интересы, личные интересы своих сотрудников. И мы возвращаемся к первому складу, где подразделения разваливаются «в никуда» друг от друга. Старайтесь начальника склада «подтягивать наверх». На нормальном складе участие начальника склада в оперативной работе минимально. То есть, как начальник склада – он пусть больше работает с отделом продаж, с транспортным отделом, с бухгалтерией – но, ни в коем случае – не управляет все время оперативной деятельностью. Потому что, если начальник склада все время управляет оперативной деятельностью склада – где-то что-то плохо (и необязательно на складе!). Это – верно на 100%.

Как я сказал – многие принципы логистики склада не зависят от отрасли.

Я для себя выделил следующие общие принципы:

• Все считайте. Чем раньше начнете считать, тем лучше.

• Избегайте «бутылочных горлышек». Планируя склад – переехали на склад, наставили стеллажей, вроде все хорошо. А в итоге в качестве площадки для приема имеем 20 квадратов, куда еле-еле фура входит. Но в зоне приемки же еще должно быть место для того, чтобы товар расфасовать, расставить… Об этом никто не подумал. Чем меньше площадь, тем больше проблем.

• Упрощайте принципы/регламенты работы. Все большие WMS-системы сводят все к одному принципу, грубо говоря, к принципу «конвейера», к принципу «простых операций». Самый простой пример: зачастую – как происходит работа? Сборщик получает задание на сборку – например, в бумажном виде. Он идет, собирает, тут же упаковывает. Даже в такой тривиальной ситуации гораздо выгоднее четко разделить: отдельно сборку сделать и отдельно упаковку. Люди со-

– 11 –

бирают. Вывезли куда-то, в зону поставили отдельно, люди пакуют. Вы здесь сразу разделяйте сложную задачу надвое. Низовой персонал, задача которого иметь крепкие руки и спины, быстро ходить по складу и собирать товар. Этот персонал не должен заботиться о том, хрупкий товар/не хрупкий, им не нужно что-то аккуратно упаковывать. Соберут/упакуют другие люди. Даже на таком простом эффекте, на длительном промежутке у вас будет существенный выигрыш. И вам это даст взаимозаменяемость персонала. У вас сотрудник, который собирает/упаковывает, у него всегда квалификация выше должна быть. Если вы их разделили – у одного квалификация выше, у другого чуть пониже, и этого «низкого» вы можете менять в любой момент. Умные головы не зря придумали конвейеры...

• Не допускайте складской персонал к логистике склада. Поясню на примере. После вынужденного отсутствия у себя в компании возвращаюсь и обнаруживаю, что персонал, ничего не согласовав, переставляет стеллажи. И делают проход между стеллажами шириной метра под 2. Подхожу, спрашиваю: «Для чего?» Мне отвечают: «У нас сборщик ходит с рохлей (паллет 120х80см). Вот, если два сборщика войдут в один проход, нужно место, чтобы им разминуться в проходе». Я спрашиваю: «Извините, у нас 10 проходов. И у нас в среднем собирает товар 10-11 человек. Для чего делать широкие проходы, если в среднем, в проходе почти всегда будет один человек?» Это просто иллюстрация того, что думать и планировать должны люди, которые смотрят немножко вперед и которые знают, к чему приведет. В итоге, вместо 2 метров мы сделали проход 132 см. Этого достаточно для того, чтобы сборщик с рохлей себя нормально чувствовал и этого достаточно даже для того, чтобы туда въехал вилочный погрузчик. В итоге удалось организовать еще один полноценный ряд за счет сэкономленной площади, а это примерно 300 ячеек получилось. А иначе пришлось бы изобретать что-то более тяжелое.

• Избегайте альтернатив. Это, я считаю, основное правило, которое я бы впрямую мог вам порекомендовать. Как только у сборщика, маркировщика или у упаковщика есть альтернативы, он всегда будет выбирать то, что удобнее ему. То, на чем он сможет где-то сэкономить свои силы, чуть-чуть упростить регламент. И это в итоге приводит к проблемам. Чем меньше альтернатив – тем выше качество обслуживания. За счет чего это происходит? Вы немножко теряете в скорости. За счет того, что у вас альтернативы нет – есть жестко зашитый вариант. Вы немножко теряете в гибкости. Но эта потеря окупается стократно тем, что это предсказуемые действия. То есть, вы точно знаете, что они будут выполнены точно, правильно и в срок. Суммарно это дает эффект. Естественно, ни в коем случае не нужно складской персонал рассматри-

INFOSTART JOURNAL №2 НОЯБРЬ 2013 вать как людей низшего сорта. Мы уже говорили, что именно персонал – самое важное звено в работе склада. Именно от усилий персонала зависит качество обеспечения клиентов. Поэтому для того, чтобы достигнуть успеха, нужно делать удобные для склада вещи. А для того, чтобы понять, что должно быть удобно для складского персонала, надо самому покрутиться на складе. То есть, если вы делаете автоматизацию сами, как сотрудник IT-отдела фирмы – мало того, что вы там беседуете с начальником склада, возьмите в руки рохлю, возьмите в руки листы, походите день-два. По два-три-четыре часа. Может, даже больше. К исходу второго-третьего дня вы поймете, что не все так просто, как казалось «сверху» – со своей комнаты с компьютером. К концу дня реально «клинит» от обилия цифр на листах, от необходимости совершать кучу действий. И тут становится понятно, на что нужно нацеливаться. Нужно нацеливаться на удобные интерфейсы. То есть, не должно быть ничего лишнего, что могло бы отвлекать от текущей операции, которая должна быть выполнена в данный момент.

Это мой склад. Вверху вы видите обычную складскую балку. Слева и справа видим этикетки. Казалось бы, практически одинаковые. Но опыт работы показал, что наклеивать этикетки так, как на картинке слева, принципиально неверно. Правильно так, как справа. Заметили разницу? Стрелки по краям и сами этикетки дальше друг от друга. Об этом даже не думали. Но, как оказалось, к концу дня уже реально «клинит» и попытки совершить неправильные действия – увеличиваются. А когда совсем чуть-чуть переделали, сделали как указано справа, количество попыток сделать ошибочные ситуации стало гораздо меньше. На двух картинках ниже показана балка с этикетками для верхних стеллажей – 4-5-6 ярус. Для такой высоты этикетка наклеена должна быть именно так, как в примере – под обрез (нижняя картинка). А не абы как, главное чтобы было. Казалось бы, мелочь, а в результате приводит к чему – ездит большой штабелер и, если этикетка наклеена где-то посередине балки, ему приходится притормаживать, чтобы ее отсканировать (стоящая паллета перекрывает доступ к этикетке). А если она наклеена под нижний обрез, он сразу поднимается на нужное место без притормаживания и сканером бьет – паллета не мешает. Всего, казалось бы, 10-15 миллиметров разницы, как наклеить этикетку, а экономия 2-3-5-10 секунд. За день – набегают минуты, за месяц – набегает существенное время.

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

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

• Еще один совет, выполнение которого я считаю необходимостью: линейный персонал склада (то есть низшее звено) должен быть постоянно в легком напряжении. Это не значит, что ему нужно заниматься бестолковой работой (ломиком склад подметать), но эти люди ни в коем случае не должны вообще никогда сидеть, каждую минуту рабочего времени они должны делать чтото полезное. Только тогда склад будет понимать свою значимость, что он делает полезную работу, которая оплачивается. Фирма платит за рабочее время. Нет заявок – проводите дефрагментацию склада. Все продефрагментировали? Вспомните, давно ли вы паллеты с ряда вытаскивали – сколько там мусора? Люди на складе работают, дышат этой пылью. Работа на складе есть всегда, и есть всегда нужная работа.

– 12 –

Приемы повышения производительности 1С Андрей Гилев Teamleader в команде gilev.ru, эксперт по производительности, руководитель проектов. Провел нагрузочное тестирование на 3000 рабочих мест.

От ведущего: Есть теория, есть практика, а есть методика (это где-то посередине). Когда нет практики и отсутствует желание читать теорию – в поисковик мы идем за методикой. Собственно – Андрей Гилев.

Меня зовут Андрей Гилев. Я работаю в команде gilev.ru. Мы являемся выделенным подразделением Раруса, которое на практике занимается вопросами производительности и масштабными проектами 1С. Начнем с начала. Откуда вообще в 1С появились вот эти задачи по производительности, и почему они, в общем-то, такие – достаточно непростые.

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

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

И поэтому ее цель – она усредненная. И возникает вопрос – да, вроде, система работает хорошо. Но что будет, если у нас будет 30 пользователей? Система точно будет работать хорошо? Что будет, когда пользователей будет 300? Возможно ли, чтобы и тогда система работала хорошо? А что будет, когда пользователей будет 3000?

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

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

Влияние на производительность различных факторов

Соответственно, почему вот это отношение – двоякое? Потому что даже у обычных клиентов есть некоторое заблуждение, что есть типовая платформа, есть типовая база (предположим, там программисты еще ничего не успели «напортить»),и она должна работать хорошо.

Чтобы не быть голословными – давайте перейдем к примеру.

На этом видео рассматривается пример достаточно такого усредненного сервера, который совмещает и сервер СУБД, и сервер 1С. В этом примере мы проверяем, что в свойствах сервера установлен максимальный размер памяти сервера 20000 Мб.

– 13 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Это именно та скорость, которую, в общем-то, мы ожидаем от 1С.

А сейчас мы проведем эксперимент над нашей якобы типовой конфигурацией, с типовым, не тронутым сторонними программистами кодом. Мы установим в свойствах сервера максимальный размер памяти сервера уже не 20000 МБ, а 600 МБ. Также здесь поставлена стандартная конфигурация Бухгалтерия Предприятия 3.0. Перед работой – для чистоты теста – у нас сейчас очищается кэш.

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

И сделаем ту же самую операцию – нажмем кнопку «Заполнить» в документе «Формирование записей книги покупок». Обычный пользователь в большинстве случаев не знает, что там творится с памятью на серверах. Тем не менее, он начинает видеть уже совершенно другую картину. Например, он видит, что – ждем… ждем… неизвестно чего ждем. Хотя, например, вчера – он всю ту же операцию реально проводил за секунды.

И обычно такие пользователи не конкретизируют, они просто говорят: «У нас все сломалось, система не работает!» Сейчас операция, согласно замерам времени АПДЕКС, выполнялась 51 секунду.

Мы нажали в документе кнопку «Заполнить», и система у нас теперь сколько-то думает (не очень продолжительное время, примерно 20 секунд). Это – первая итерация. Мы можем проверить по замерам времени – да, 19.882 сек.

Когда мы делаем вторую итерацию (еще раз в этом же документе нажимаем кнопку «Заполнить»), как и во всех системах, собственно говоря, как и в SAP-е и в других – табличная часть заполняется очень быстро. По замерам времени – 1.482 сек.

В этом примере гораздо интереснее другое. Интересно изменение поведения системы, потому что,нажимая второй раз на кнопку «Заполнить», мы ожидаем, что система могла бы сработать сразу и выдать результат сразу. Казалось бы – почему нет?

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

– 14 –

Андрей Гилев

Приемы повышения производительности 1С

Собственно говоря, первый шаг в методике повышения производительности – это понять, что происходит, попытаться это как-то расследовать. И, сейчас в стандартном Performance Monitor мы просто посмотрим нагрузку на диск (показатель «pagereads/ sec») – то есть, сколько страниц в секунду считано.

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

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

То же самое, если мы уже углубляемся в некоторые показатели. Там можно посмотреть, что происходит достаточно много интересного. Можно обратить внимание на показатель «buffercachehitratio» – коэффициент попадания в буферный кэш. Этот показатель показывает, насколько полно SQL-сервер использует кэш и, соответственно, показатель, близкий к сотне, – это очень хорошо: он означает, что данные уходят в кэш и используются из него.

В начале примера мы проверяем в свойствах сервера, что максимальный размер памяти сервера у нас 20000 МБ – то есть, памяти у нас сейчас будет хватать. Опять-таки, очистим кэш, чтобы он не влиял на процесс.

В документе «Формирование книги покупок» нажимаем кнопку «Заполнить». Сейчас система достаточно быстро выдаст результат – по замерам времени получилось 6, 636 сек. Будем считать, что это вполне достойный результат – из-за него переживать нет смысла. Сейчас мы опять проведем эксперимент – проэмулируем нагрузку на жесткий диск. Предположим, у нас в системе кроме нашего SQL-сервера еще какие-то ресурсы что-то читают или пишут. В этом эксперименте мы запустили тест CrystalDiskMark, который генерирует такую нагрузку.

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

Здесь – нижняя черта (серая) – это, как раз-таки память, которую мы урезали с 20000 до 600, и сразу стало видно, что нагрузка на диск резко возросла.

Можно подумать, что дело просто в железе и нужно или память докупить, или еще что-то. Но не стоит торопиться. Рассмотрим второй пример.

Теперь, в момент, когда диск загружен, опять нажимаем кнопку «Заполнить» в документе «Формирование книги покупок». То есть, конфигурация типовая,

– 15 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 код, выполняемый системой – тот же самый, память доступная – та же самая. Казалось бы – почему системе не работать так же?

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

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

• и инструменты. Это стандартные инструменты, которыми можно пользоваться: —— технологический журнал, —— профайлер, —— ЦУП, —— Счетчики производительности

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

Теперь остановим нагрузку, генерируемую нашими тестами.

И для чистоты эксперимента – проведем ту же операцию. Теперь табличная часть заполнится очень быстро.

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

– 16 –

• Опять-таки, есть прекрасная штука ЦУП – он мне когда-то очень нравился. Потому что он был очень знакомый, родной… Мы пользовались им практически на каждом проекте. И, когда мы из своих соображений уходили с этого ЦУП, я как раз относился к этому с негативом и не понимал – он ведь работает, почему нет? Но у того же ЦУП, кроме того, что он собирает только часть данных, которые нам хотелось бы видеть, есть ограничения по настройке (там достаточно «капризная» настройка, и ограничение у него потому, что он собирает только часть данных). Там нельзя в полной мере мониторить из-за того, что логи разрастаются очень сильно, и могут случиться нехорошие ситуации с ними.

• К чему мы пришли? Мы пришли к тому, что нужен какой-то инструмент, который позволил бы быстро собирать все эти данные– не тратить день на настройку, собирать «на лету» и видеть некоторую «агрегацию» этих данных. Собственно говоря, для нас решением было, используя все механизмы стандартных инструментов, приведенных выше, собрать эти данные воедино и потом полученные в результате данные пересылать в одно место и там уже агрегировать. Потому что – что получалось на практике? Да, мы можем посадить специалиста на ЦУП, на разбор технологического журнала. Но все эти операции занимают очень и очень много времени. И это время тратится неэффективно, потому что это рутинные операции. Сервисыgilev.ru, которые мы используем, действуют по принципу Google, то есть они бесплатны не только для нас.

Андрей Гилев

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

Еще есть такой момент: при анализе собственными силами, и даже тогда, когда к нам клиенты обращаются, так или иначе, встречается мнение, что хочется клиенту увидеть одну волшебную «галочку». Они говорят: «Вы нам сейчас быстро сделаете какую-то настройку, и у нас все заработает быстро». Это, конечно, прекрасное заблуждение.

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

Пример оптимизации запроса

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

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

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

Итак, из плана запросов мы видим, что в запрос попадает немало строк – и при этом оптимизатор запроса ошибается в их оцениваемом количестве строк таблицы, и, соответственно, происходят некоторые неэффективные вещи.

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

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

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

– 17 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 В данном случае – с чего, например, можно начать?

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

• У нас есть такой прекрасный оператор «НЕ», который показывает, что, возможно, в этом месте есть какая-то большая или неэффективная выборка, которая нам может портить производительность.

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

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

Это решение тоже сугубо практическое. Чем практика отличается от теории? Решение зависит от того, какой объем данных будет обрабатываться. То есть, на такой же операции на других примерах мы, возможно, и не получили бы эффекта. Но тут, пусть даже мы выборку эту не сделали сначала, все равно, из-за того что потом отборы попали в индекс, на этом выиграли то преимущество, которое мы хотим.

• Следующая часть оптимизации этого запроса – это разделение запроса. То есть, в реальности такие запросы выглядят как длинные-длинные листинги, состоящие из многих частей. И разделение запроса – практически классика.

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

– 18 –

Андрей Гилев

Приемы повышения производительности 1С

• В этом примере очень показательно, что рядом с «НЕ» мы видим некоторое место, которое можем оптимизировать (обведено оранжевым цветом).

В результате всех этих действий – у нас именно этот запрос (самый первый, который был в проблемах) ускорился в шесть раз!!

Выводы

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

Что тут нужно сказать?

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

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

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

– 19 –

• Да, есть теория. Теорию нужно применять на практике. Но – достаточно внимательно. Потому что теория очень сильно «плавает» из-за того, что у вас попадает на вход. То есть, если вы что-то оптимизируете, и нужно смотреть, какой объем данных приходит к вам.

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

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

INFOSTART JOURNAL №2 НОЯБРЬ 2013 решать многоплановые задачи, учитывать различные параметры – внешнее воздействие на систему, оптимизировать какой-то неправильный код, еще что-то… Можно решить проблему гораздо проще, если, пока система находится в «работоспособном состоянии», мониторить достаточно ограниченное количество ключевых показателей, чтобы потом не допустить ошибок.

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

В заключение

Что хочу сказать в заключение – есть еще один небольшой секрет, как улучшить свою производительность.

Достаточно трех:

• Мониторинг значений APDEX. Я думаю, все знают, что это такое – это вещь типовая. Нона практике часто получается, что APDEX-ом не пользуются или пользуются неправильно. Хотя он простой. Потому что может вдруг оказываться, что его неправильно настроили из-за халатного отношения–и тогда будет ситуация, что он весь зеленый, и проблемы у пользователей все равно есть. Поэтому иногда у людей возникают мысли, что это неподходящий для них инструмент. На самом деле, APDEX – очень хороший инструмент, но нужно тоже уметь им пользоваться. Соответственно, когда вы сдаете какую-то задачу на производительность, хорошо настроенный APDEX – это один из самых важных показателей • Счетчики производительности

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

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

– 20 –

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

• толстый клиент управляемого приложения c установленным свойством конфигурации «Использовать обычные формы в управляемом приложении»

Вступление Здравствуйте! Меня зовут Старых Сергей. Я занимаюсь разработкой на 1С уже 10 лет и хочу рассказывать о подсистеме «Инструменты разработчика».

• В остальных режимах есть только поддержка некоторых программных отладочных функций, в том числе на стороне сервера

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

• Предусмотрено простое подключение подсистемы к вашей конфигурации

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

• Существует мобильный вариант инструментов в виде набора внешних обработок с рядом ограничений, выпускаемый Антоновым Василием

Общая информация

• Основной сайт подсистемы – devtool1c.ucoz.ru

• Подсистема бесплатна

—— На нем обеспечено свободное скачивание

—— В том числе для коммерческого использования

—— Дополнительно подсистема публикуется на сайте infostart.ru

—— Веб-сайты подсистемы сразу находятся любым поисковиком по запросу «Инструменты разработчика»

• Подсистема развивается уже 6 лет

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

• Интеграция инструментов

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

• Подсистема ориентирована на использование в обычном приложении

—— Подавляющее большинство форм в ней обычные

—— Такая позиция планируется и в будущем

Контекстная подсказка

Первый кирпичик подсистемы. Сначала даже выпускалась в виде отдельной подсистемы. По сути, является дополнительным расширением для поля текстового документа для редактирования программных текстов. Главная функция – это отображение списка возможных слов в любом месте текста на основе вычисленного контекста. Обычно такую функцию называют контекстной подсказкой или авто дополнением. В конфигураторе такая функция присутствует с рождения платформы версии 8, но ей очень далеко до Телепата для платформы 7.7, за который огромное спасибо хочется сказать Александру Орефкову.

—— Отмечу, что конфигурации под управляемое приложение часто вполне работоспособны и в режиме обычного приложения —— Какие режимы запуска клиента поддерживает подсистема?

• толстый клиент обычного приложения

– 21 –

• Контекстная подсказка подсистемы поддерживает все родные языки платформы —— Встроенный язык —— Язык запросов

—— Язык выражений компоновки данных

—— для языка запросов и выражений компоновки данных – до сих пор единственная известная мне полноценная контекстная подсказка и справка

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Ее можно программно подключать к любому полю текстового документа. Для этого в целевую форму нужно добавить всего несколько функций.

• В подсистеме она подключена ко всем редакторам программных текстов • Эта подсказка умнее аналога в конфигураторе

—— вычисляет типы в пределах применимости

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

• можно открывать синтакс-помощник по любому свойству или методу

—— определяет, какую страницу справки открывать для текущего слова

• можно интерактивно изменять значения свойств

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

• Она понимает явное указание типов, т.е. можно для переменной в комментарии указать, какой она имеет тип

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

• Обеспечивается подсветка ошибочной строки текста —— при синтаксическом контроле

• исследователь позволяет исследовать глобальный контекст

—— при выполнении программы

• Есть поддержка шаблонов текста из файлов шаблонов платформы (st)

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

• Функция подсказки по параметру метода открывает страницу синтакс-помощника и выделяет текущий параметр

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

• для исследования коллекций служит отдельная форма

Двойным кликом по количеству элементов открываем коллекцию в исследователе коллекций. Оттуда можем открыть элемент коллекции снова в исследователе объектов. Все методы объекта свернуты в ветке Методы. Функции без обязательных параметров можно прямо здесь выполнять двойным кликом. Можно включить режим автосправки по текущему слову, т.е. при смене текущей строки будет отображаться страница справки по ее слову. Двойным кликом по схеме компоновки она открывается в консоли компоновки данных, откуда можно открыть уже конструктор схемы. Кнопкой XML можно увидеть результат сериализации значения текущей строки. Для редактирования значения нужно нажать F2.

Настройка техножурнала

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

– 22 –

Сергей Старых

Повышение эффективности разработки на платформе 1С с помощью подсистемы «Инструменты разработчика»

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

• подготовка конфигурационного файла на основе имеющихся сведений об исследуемой проблеме

Анализ техножурнала Для полного анализа логов техножурнала производитель не предоставляет инструмента. В подсистеме для этой цели служит инструмент «Анализ техножурнала».

• Он автоматически определяет текущие каталоги логов для клиента и сервера • Имеется вариант задания периода загрузки «Последние N минут»

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

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

• отключение конфигурационного файла

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

• Кнопка «Трасса» предназначена для записи в текущие журналы маркеров начала или конца трассы выполнения кода в текущем сеансе • Кнопка «Трассы» служит для поиска всех трасс в загруженной таблице и установки отбора для отображения только нужной трассы

• Форма конвертора текста из терминов БД в термины метаданных позволяет преобразовать в частности в большом числе случаев текст из терминов SDBL в обычный запрос с параметрами и открыть его в консоли запросов для анализа.

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

• обеспечивает понятное представление сложных условий

• У загруженной таблицы имеется фильтр по ссылке на объект базы данных или по имени таблицы

• имеет шаблоны настройки журнала

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

—— они позволяют максимально быстро включать нужную конфигурацию журнала —— можно добавлять свои шаблоны

• предусмотрено быстрое выключение журнала

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

• есть возможность группового добавления в условия отбора —— текущего сеанса

—— текущего пользователя —— текущей базы

• имеется большое число подсказок и пояснений

Продукты для анализа техножурнала Поясню характеристики. Реакция – скорость доставки результатов анализа оператору.

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

– 23 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Консоль запросов Флагманский инструмент подсистемы. Если для отладки кода на встроенном языке нам обычно хватает пошагового выполнения в отладчике, то для отладки запроса в платформе явно недостаточно штатных средств. Производитель предоставил нам простой инструмент – обработку «консоль запросов», позволяющий редактировать и сразу выполнять запрос в режиме предприятия. Однако возможности его очень скромны. Рассмотрим инструмент подсистемы.

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

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

—— Ну и в дереве запроса есть функции для преобразования текста запроса • Функция «Вынести в новый запрос» позволяет вынести подзапрос во временную таблицу, а на место подзапроса вставить обращение к этой временной таблице

• Функция «Преобразовать в подзапрос» поможет например, когда вам нужно перед соединением двух таблиц сгруппировать одну из них

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

—— подключена контекстная подсказка

—— есть возможность вставки ссылки на любой объект БД в виде параметра

• Есть настройка динамического отбора и порядка в режиме компоновки и построителя,

—— А также просмотр результирующего запроса с учетом этих настроек

• Возможно открытие сгенерированной по запросу компоновки в консоли компоновки

Консоль запросов

• В инструменте присутствуют обработчики «перед выполнением», строки и самого результата с контекстной подсказкой и возможностью отладки • Консоль поддерживает временные таблицы

—— конструктор запроса и контекстная подсказка

– 24 –

«понимают» типы полей существующих временных таблиц

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

• Предусмотрен вывод результата в —— Таблица значений —— Дерево значений —— Сводная таблица

—— В таблице и дереве доступен большой ряд вспомогательных функций

—— Реализована передача выбранных данных из результата в другие инструменты, например в • Подбор и обработка объектов

• Поиск дублей и замена ссылок

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

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

• В консоли реализованы вычисляемые параметры

—— для редактирования выражения предусмотрен специальный редактор на основе контекстной подсказки

—— С их помощью кнопка Период редактирует стандартную группу параметров для задания интервала времени

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

• Возможен анализ технологической трассы последнего выполненного запроса в инструменте «Анализ техножурнала»

• Обеспечивается восстановление сессии консоли после ее нештатного прерывания

Сергей Старых

Повышение эффективности разработки на платформе 1С с помощью подсистемы «Инструменты разработчика» • Исполняемые запросы макета компоновки можно передавать в консоль запросов; это поможет понять, например, как настройки компоновки влияют на исполняемые запросы и какой из запросов выполняется очень долго • Предусмотрен замер длительности этапов компоновки, включая однократное выполнение каждого запроса макета

Консоль компоновки

• Консоль позволяет исследовать —— макет компоновки —— схему компоновки

—— внешние наборы данных —— настройки компоновки

Консоль компоновки

—— Расшифровку любой ячейки

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

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

—— Табличный документ —— Таблица значений —— Дерево значений

• Для табличного документа результата

—— реализован режим автосуммирования чисел в выделенных ячейках —— имеется подменю для именованного сворачивания группировок

• При программном вызове, в т.ч. из отладчика, —— передаются следующие параметры

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

• СхемаКомпоновки

• *НастройкиКомпоновки

—— Подбор и обработка объектов

• ВнешниеНаборыДанных

—— Поиск дублей и замена ссылок

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

• Возможен анализ технологической трассы последней выполненной компоновки в инструменте «Анализ техножурнала»

• Наборы данных запросы можно редактировать в консоли запросов, т.е. со всеми присущими ей удобствами

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

—— Отключаемая поддержка внешних функций

Консоль кода

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

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

– 25 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 гократного изменения и выполнения, для чего обычно создается внешняя обработка и повторяется последовательность действий: изменить программный код, переоткрыть ее в предприятии и запустить выполнение кода. На переоткрытие внешней обработки при большом числе повторений уходит ощутимое время. В результате появился тип инструментов «консоль кода», в котором последовательность действий сведена к минимальной. Рассмотрим возможности консоли подсистемы.

ны для изменения. Разработчику же нередко требуется полный доступ ко всем полям. Такая потребность породила свой класс инструментов, представителем которого в подсистеме является «Редактор объекта БД». Рассмотрим его возможности • В нем отображаются все реквизиты и табличные части объекта, включая общие и предопределенные

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

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

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

• В редакторе кода есть возможность вставки ссылки на любой объект БД в виде параметра

• Закладка «Связанные колонки БД» служит для анализа колонок и строк таблиц БД, ссылающихся на тип объекта и на сам объект

• Код можно выполнять как на клиенте, так и на сервере

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

• Закладка «Поиск в объекте» позволяет выполнять поиск произвольного значения в данных объекта

• Также с объектом можно выполнять все основные действия

• Также предусмотрен замер времени выполнения —— Общий

• Данные объекта можно вывести в табличный документ, отредактировать там и загрузить обратно

—— И для участков кода

• У нового объекта можно редактировать уникальный идентификатор

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

• Предусмотрено исследование значения любого параметра

• Возможен анализ технологической трассы последнего выполненного кода в инструменте «Анализ техножурнала»

• Обеспечивается восстановление сессии консоли после ее нештатного прерывания • В таблице параметров поддерживаются все типы значений и для основных типов реализованы специальные редакторы

Интерфейсная панель Думаю, каждому разработчику на 1С знакомо стандартное подменю «Операции» в обычном приложении и пункт «Все функции» из подменю «Сервис» в управляемом приложении. Открыв с их помощью список объектов метаданных нужного типа, нам приходится искать нужный объект по первым буквам или использовать CTRL+F для поиска по подстроке. Этих возможностей многим не хватало, в результате стали появляться инструменты для навигации по объектам метаданных. В подсистеме для этой цели служит «Интерфейсная панель».

Редактор объекта БД Диалоги для работы с объектами БД часто не предоставляют полного контроля над данными, т.к. некоторые поля просто не выведены в них, а другие недоступ-

– 26 –

• Рассмотрим структуру ее дерева

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

Сергей Старых

Повышение эффективности разработки на платформе 1С с помощью подсистемы «Инструменты разработчика»

—— типовой справочник внешних обработок автоматически образует отдельную ветку —— дополнительно сделаны ветки

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

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

—— при его наложении строка разбивается на слова и ищется вхождение одновременно всех слов —— в процессе набора текста фильтра он применяется автоматически

• Для дерева имеется опциональный фильтр по одной подсистеме

• В контекстном меню объекта метаданных можно выбрать —— добавить объект в избранное —— открыть

• любую его статическую форму

• а также многие инструменты подсистемы

—— При выборе объекта открывается его основная форма

• Поддерживаются все типы ссылочных данных • Для поиска дублей предусмотрены

—— настраиваемый отбор компоновки

—— сравнение любого количества реквизитов на равенство и одного строкового реквизита по похожим словам

• В группах дублей

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

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

• Таблица правил замены ссылок

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

• В таблице ссылающихся объектов, заполненной по таблице правил замены

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

—— есть возможность групповой пометки по отображаемым признакам

• При выполнении замены

—— перед замещением в независимых регистрах сведений при склеивании записей открывается диалог настройки замещения

• После выполнения замены

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

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

– 27 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Подбор и обработка объектов

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

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

• есть возможность вставки ссылки на любой объект БД в текст в виде параметра

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

• В инструменте «Подбор и обработка объектов» подсистемы поддерживаются все основные типы таблиц БД —— ссылочная

—— табличная часть

Функции режима отладки

—— последовательность —— все типы регистров

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

• Заполнение таблицы строк для обработки возможно —— Как ручным подбором

—— Так и компоновкой данных

• В таблице строк для обработки

—— колонка «Результат обработки» служит для отображения результата обработки строки

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

—— колонка «Пометка» обеспечивает ручное отключение обработки строки

—— ключевые колонки выбранной таблицы БД всегда добавляются автоматически —— предусмотрен режим частичной загрузки

• Управление обходом выборки данных имеет 3 варианта

—— Основной вариант «Строки» – здесь обходится каждая помеченная строка

—— Вариант «Объекты» – тут обходится каждый объект БД, которому принадлежит хотя бы одна помеченная строка

—— Вариант «Ключи объектов» – здесь обходятся ссылки или несчитанные наборы записей; такой вариант эффективно применять для очистки регистров и регистрации изменений

• Имеются встроенные обработки данных с указанием допустимых типов объектов

—— Среди них хотелось бы особо отметить произвольный алгоритм, где

– 28 –

• Функция изменения значения переменной – Пр – присваивает 1-му параметру значение 2-го параметра

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

• Функции выполнения произвольного кода

—— Ду(…) – выполняет код с обращением к параметрам по фиксированным именами

—— Оперировать(…) – выполняет код c обращением к параметрам по произвольным именам

• Функция исследования объекта – Ис() – открывает объект в исследователе объектов или коллекций

—— функция поддерживает отложенное выполнение – при вызове на стороне сервера делается снимок объекта и записывается в справочник «Объекты для отладки», откуда он может быть использован уже на клиенте для открытия в исследователе

• Функция открытия специализированных консолей – От()

Сергей Старых

Повышение эффективности разработки на платформе 1С с помощью подсистемы «Инструменты разработчика»

—— варианты использования в зависимости от типа первого параметра

• если передан запрос, то открывает его в консоли запросов

• если передан построитель запросов, то открывает его результирующий запрос в консоли запросов • если передан построитель отчета, то открывает его в консоли построителей отчетов

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

• В параметрах такого запуска

—— есть возможность временно предоставить роль «Разработчик (ИР)», что позволяет использовать все возможности подсистемы только в запускаемом сеансе, но не в других сеансах этого пользователя

• если передана схема компоновки, то открывает ее с настройками и внешними наборами данных в консоли компоновки

—— функция поддерживает отложенное выполнение; при этом вместе с запросами в снимок сохраняются и их временные таблицы с ограничением числа строк

• Функция вычисления входящих в запрос временных таблиц – ПолВТ() —— для запроса получает структуру всех входящих в запрос временных таблиц —— для менеджера временных таблиц и имени таблицы получает только одну таблицу

• Функции обозначения начала/конца трассы техножурнала – ТехН()/ТехК() – они записывают специальный маркер в техножурнал —— Анализ этих трасс выполняется в режиме предприятия инструментом «Анализ техножурнала»

Тестирование метаданных – 2/42

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

• Функция открытия параметров в консоли кода – Оп() – открывает консоль кода и передает ей все свои параметры —— изменения параметров возвращаются в вызывающий контекст —— интерактивная

• Тестирование форм управляемых и обычных

—— Выполняется создание, открытие и закрытие

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

—— Тестируется ряд типов элементов управления путем вызова некоторых их событий

• Тестирование прикладных объектов

—— Выполняется создание, копирование, запись, проведение, отмена проведения

• Поддерживается тестирование внешних метаданных из выбранного каталога

• Все операции выполняются в отменяемых транзакциях

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

• Результаты Здесь показано, как вызывать функции из отладчика.

Работа от имени пользователя

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

– 29 –

—— в основном представляются в виде таблицы с указанием полного имени модуля и описания ошибки —— позволяют быстро переходить к строке модуля в конфигураторе

Кейсы как инструменты работы с клиентами Фарит Насипов Консультант по производственному учету и прикладным инструментам управления

www.nasf.ru

Думаете, как удвоить продажи услуг? С помощью кейсов. Которые работают.

Традиционный учебный кейс…

Мы в проекте «Один Курс» интуитивно чувствовали, что продажи с помощью кейсов очень эффективны. Еще 2008 году мы предлагали такую схему нашим новым партнерам. Но лучше один раз попробовать, чем 100 раз посоветовать. Поэтому, в прошлом году, проектируя линейку курсов по «1С: Управление Торговлей», мы поняли – пора! Если вы знакомы с продажами интеллектуальных продуктов, то знаете, что грамотное планирование позволяет давать весьма точную оценку объема продаж. И мы, как правило, еще до запуска курса в продажу знаем и количество комплектов, которые будут проданы, и плановую выручку. Погрешности случаются, но в пределах 7-10%. За весь наш 6-летний опыт на рынке учебных курсов по 1С, мы всего лишь дважды ошибались в оценке объема продаж: в 2012 году с курсом по «1С: Зарплата и Управление Персоналом», и в этом году – с курсом по «1С: Управление Торговлей».

Перед началом продаж курса по УТ мы проводили флешмоб «УТ 11 – Быстрый Старт». Внимательно следили за активностью участников. Поэтому, еще до запуска, мы уже знали, что будет продано примерно 360 комплектов. И тут возникла идея переписать курс в формате кейсов. Результат? Объем продаж вдвое превысил наши ожидания!

… это «как бы привычный формат кейсов». Проповедники западного подхода на базе бизнес-школ и ВУЗов внедрили эту мысль в головы большинства менеджеров. Так появился термин «Casestudy» – обучение на основе кейсов.

Рисунок 1. Структура классического учебного кейса В классическом варианте – это те примеры, которые вы могли видеть, если учились по кейсам в ВУЗах или в программах MBA. Рассматривается некая вводная ситуация с учетом начальных условий предприятия, а также тех вызовов, с которыми компания столкнулась. Кейс посвящен разбору всевозможных мер, принятых для решения ситуации, а также анализу полученных результатов.

Пример традиционного кейса:

Но при чем тут продажа услуг?

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

Почему? Потому что кейс внутри себя гармоничен и самодостаточен. К тому же, он заранее закрывает потенциальные сомнения клиента. Но тут есть одна тонкость. Короткое слово «кейс» скрывает в себе два совершенно разных понятия: • Традиционные учебные кейсы (программы MBA) • «Кейсы, которые работают ™»

Итак, что мы видим в таком учебном кейсе?

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

– 30 –

Фарит Насипов

Кейсы как инструменты работы с клиентами

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

Источник: A Case Study of ERP Implementation for OptoElectronics Industry, Table 3: The ERP Checklist

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

Из каких блоков состоит этот кейс?

• Первый блок – это блок «TheClient» – описание ситуации у клиента;

Таким образом, объем кейса может достигать и 90, и даже 150 страниц.

• Второй блок – «TheChallenge» – то есть, это та проблема, с которой клиент столкнулся;

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

• Третий блок – «TheSolution» – здесь анализируется, какие варианты могли бы быть применены, какой вариант мы выбрали и почему. Здесь приводится также экспертное мнение. Хитрости, ходы, тонкие места и т.д.;

Именно поэтому, наша задача – делать кейсы на одну-две страницы, то есть…

… научиться создавать «Кейсы, которые работают ™»

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

• И, самый приятный момент, – это последний блок «TheResult», или иногда этот блок называется «TheBenefits» – то есть, это то, что клиент в итоге получил.

И это далеко не единственный вариант. Вот еще один кейс с такой же структурой от другого поставщика. Однако, обратите внимание, описание компании не выделено, как пункты Challenge, Solution и Results, оно обособлено. Данная обособленность актуальна в контексте еще одной особенности этого материала, дело в том, что в этом PDF-файле сразу три кейса, три клиента – и вся эта структура три раза повторяется:

– 31 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 И вот еще один пример. Это – точная калька с западного, но только от поставщика из России. Единственное отличие – это пункт «Индустрия». Он появился здесь потому, что данный кейс является широкозахватным. Это – специальный одностраничный PDF, для того, чтобы из пачки таких кейсов можно было составить нормальный MarketingToolkit.

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

Структура кейса, который работает Итак, есть всего 4 базовых пункта. Почему используется именно такая структура? Это не случайно: дело в том, что при таком оформлении практической ситуации у клиента возникает несколько точек конверсии (готовность купить ваш сервис/ товар/услугу): Пункт

Суть

«TheClient»

Ситуация

«The Challenge»

Экспертиза

«The Solution»

«TheResult»

Описание решения Результаты и эффекты

Содержание пункта

• Описание предприятия, проблемы • Постановка задачи

• Генерация вариантов решения • Анализ вариантов

• Выбор лучшего + особенности • Детали выбранного решения • Цифры

• Отчеты

• Впечатления и отзывы клиента

– 32 –

Точка конверсии

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

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

Фарит Насипов

Кейсы как инструменты работы с клиентами

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

Не просто – «ты научишься программировать…», а измеримые результаты – что конкретно сможешь делать, какие задачи решать. Это не оферта, но сильное обещание. Почему? Просто мы говорим, что мы это уже делали. Вот сроки, и вот гарантированный результат. Клиент интуитивно понимает, что, раз мы это делали, то, наверное, у нас уже есть устоявшийся прайслист на эту категорию сервисов / услуг.

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

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

Еще одно преимущество кейса – быстро и просто. Людей сейчас редко волнуют академические исследования. Востребованы быстрые и простые результаты. И кейс – как раз такой формат, который доступен широкой части аудитории.

Проблемы, решаемые с помощью кейса

Мы преодолеваем четыре общих фактора сопротивления.

• Неочевидны личные выгоды покупателя («Не увидел ПОЛЬЗУ ДЛЯ СЕБЯ»);

• Есть более приоритетные задачи («Это мне интересно, но есть более срочные задачи», «Не зацепило настолько, чтобы отнять время у текущих задач»); • Недостаток доверия (то, что вслух не произносится: «Пионеры какие-то», «Какие-то они странные», «Что-то слишком дешево», «Не может быть»);

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

Базовые средства повышения доверия

Вообще, существует несколько принципов формирования доверия.

• Личный опыт – возможность самому «потрогать»:

—— Пробные образцы (например, «тест-драйв курса»);

—— Пробный период (например, «УТ 11 – Быстрый Старт»);

• Конкуренция («А вот у тех – дешевле/ солиднее / более официально...», + давление конкурентов).

—— Do-It-Yourself.

• Чужой опыт (социальное подтверждение):

Основная трудность в продажах – это преодолеть недоверие

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

—— Отзывы;

—— Примеры внедрений; —— Кейсы;

И кейсы используют сразу несколько таких способов повышения доверия: • Демонстрация возможностей

• Технические подробности продукта • Есть чужой опыт

– 33 –

• Есть отзывы

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Есть примеры

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

Как усилить впечатления клиента?

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

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

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

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

Потому что это своего рода подтверждение профессионализма. Клиенту становится ясно, что он не первый у этого «доктора», что этот «доктор» уже кого-то до этого «оперировал» и были случаи, когда это помогало. Это, конечно же, лучше, чем прийти к кардиологу, чтобы услышать: «У меня сегодня первая операция. Если будут дрожать руки – простите». Поэтому отзывы, собираемые в кейс, проходят специальную подготовку. За рубежом даже есть специальные компании, которые занимаются для других клиентов подбором отзывов.

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

Ход конем… Троянским.

Есть еще тактика «троянского коня». Мы ведь ничего не продаем в кейсе. Мы ничего не делаем. У нас нет фактора продажи в кейсе. Есть просто некое обещание, что, если такая ситуация случилась: «Приходите, мы это делали! Почитайте, как порадовались те люди, которые этому же воздействию были подвержены!» И еще. Люди очень хорошо чувствуют, когда отзыв написан искусственно. Поэтому, отзыв, естественно, должен быть написан самим клиентом. Не должно быть такого, что отзыв написан секретарем, потом отправлен клиенту, тот ставит печать и отправляет обратно. Иначе весь этот отзыв, надиктованный нами на диктофон и составленный нашим же секретарем, но зато заверенный верной печатью клиента, этот отзыв, состоящий из предложений на три десятка слов, имеющих причастные и деепричастные обороты, все-таки производит двоякое впечатление.

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

– 34 –

Фарит Насипов

Кейсы как инструменты работы с клиентами

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

Кейс – это отличное средство для демонстрации экспертизы.

Накатанная, но скользкая дорожка

Экспертиза – это демонстрация того, что читатель не знал или не мог учесть раньше.

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

Причем, кейс в отличие от сотрудника не ляпнет лишнего и не «напортачит». А это – полезное качество любого продавца.

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

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

Как бы то ни было, чем честнее вы ведете себя в подобной ситуации, тем лучше.

Два уровня подачи в кейсе – директору и техническому специалисту

Вторую и третью часть кейса («TheChallenge / Экспертиза» и «TheSolution / Описание решения»), как правило, читают две категории людей. Кто же эти люди?

Допустим, кейс попал на стол директору. Специально для него, подача в кейсе идет «к результату». То есть, в кейсе будет написано: «стало вот так и так», «достигнут такой-то эффект», «получен такой измеримый результат», «можно сформировать такие-то отчеты» и т.д. Но все равно директор потом отдаст этот кейс техническому специалисту. И этому техническому специалисту будет глубоко наплевать на всю эту подачу «к результату». Ему гораздо больше интересно, как мы, например, маршрутизировали RDP-запросы или настраивали технологический журнал. Ему интересна информация на его уровне понимания.

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

«Фишкинг»

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

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

Метакейсы – кейсы, построенные на абстрактных ситуациях

Пожалуй, каждый из нас остерегается плодить «Демонов Максвелла» – нести в реальный мир некие абстрактные казусы.

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

Соответствующий западный термин – «метакейсы». Это кейсы, построенные на абстрактных ситуациях, а не на внедрении у конкретного клиента.

Такой кейс, как правило, уже не двухстраничный. Он содержит 6-8 страниц с разбором той или иной штатной ситуации из программы MBA и/или настольной библиотеки бизнесмена.

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

Связь с авторами

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

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

Преимущества формата

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

– 35 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 но:

Кейсы за рамками обучения. Применение

В кейсе уже заложены все эти 4 этапа одновремен-

• Формирование интереса, желания – кейс это обеспечивает своим первым пунктом («TheClient / Ситуация»);

• Доверие, связь – обеспечивается четвертым пунктом («TheSolution / Описание решения») и третьим пунктом («TheSolution / Описание решения»). Наличие технических решений, «фишек», отзывов и пр. – вторым пунктом («TheChallenge / Экспертиза»); • Доказательства – само наличие кейса со ссылкой на компанию. Реальная фотография, реальные отзывы клиентов, реальные телефоны и, что самое главное, реальный опыт решения вопросов; • Примеры – кейс является примером. Это инструмент.

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

Обучение по кейсам

Что мы сейчас сделали? Мы взяли учебный коммерческий курс и перепаковали его в формат кейса.

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

Пример первый (традиционный видеокурс): допустим, есть некий курс, и в одной из глав запланировано изучение регистров бухгалтерии. Так вот, обычному человеку не нужны «регистры бухгалтерии». Как они могут повлиять на улучшение его личной жизни? Конечно, можно надеяться на то, что он себе в голове достроит сценарии использования вновь полученных знаний и навыков. Или не достроит? Увидит ли он вообще взаимосвязь между содержанием урока и своими перспективами? Большой вопрос.

Вы можете применять «Кейсы, которые работают» не только при обучении, но и во многих других ситуациях: • Предпродажная демонстрация • Продажа проекта

• Обучение клиентов в рамках проекта

• Описание собственных решений на сайте • Создание инструкций

Пример продажи проекта с помощью кейсов: у нас, в проекте «Один Курс» выдача курса на данный момент сознательно производится на электронных носителях.

А через какое-то время мы запустим в продажу физический пакет. Там будет 65 отдельных, полностью разобранных кейсов. Просто представьте себе покупателя этого курса, который вместе с записями и обучающими материалами, получает папку с пакетом кейсом. Он может прийти к клиентам и эти кейсы разложить на столе. А это уже не просто продажа услуг Специалиста в 1С, это работающий эффективный способ дать клиенту обещание: «Да, я знаю, как это сделать. Интересно? Я готов это реализовать у вас». Понятно, что кейсы будут расширяться, здесь только продемонстрирована возможность усиления продукта путем оформления его в виде кейсов.

Что дальше: витрина

Развивая идею кейсов, веером раскиданных на столе директора, зададимся вопросом: «Куда это все ведет?»

Пример второй (традиционная статья): та же самая ситуация возникает, когда клиенты читают статьи. Допустим, вы пишете на Инфостарте про IP-телефонию и стыковку с 1С. Это, конечно же, золотая ниша, к тому же там много интересных фишек. Но! Описание реализации протокола, или диаграммы взаимодействия – никак не связаны с жизнью читателя. А вот показать Специалисту в 1С, что он может инвестировать 20 часов, и в результате демонстрировать работающие прототипы клиентам (а затем продавать решения) – это уже интересно.

– 36 –

Фарит Насипов

Кейсы как инструменты работы с клиентами

На витрину! «Витрина» – это заготовленный набор шаблонов кейсов, очень эффективный инструмент презентации компании. То есть, перед продажей мы выбираем ряд кейсов, подходящих именно для этого клиента, и проводим демонстрацию по ним. … Где-то еще в 2005 году, когда 1С:Консалтинг был на взлете, бурно обсуждались идеи типового тиражного консалтинга. Один из вариантов реализации такого консалтинга – «мелкая нарезка» на мини-кейсы.

Допустим, что у вас есть наработанные 20-30 кейсов. Что мешает прямо на них написать цену? Или диапазон цен, неважно. Просто представьте, что ваши разносчики ИТС, вместо того, чтобы прийти и просто молча, низко поклонившись, отдать ИТС, отдают еще и пачку этих кейсов. Есть шансы, что хоть один кейс, да сработает? Конечно есть, и вероятность этого высока!

Что дальше: меню Что будет дальше с этой методикой? Те из вас, кто хотя бы пробежался глазами по заголовкам этой статьи, поймут наверное, что за кейсами будущее в: • Демонстрациях; • Вебинарах;

• Презентациях продуктов клиентам.

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

Ну а первый, кто сделает шаблон из хотя бы 20-50 кейсов, будет «впереди планеты всей».

Вновь заглядывая за рубеж, мы обнаружим, что эти кейсы давно оформляются как книги или буклеты. Можно прийти (или скачать) и полистать. А в конце – форма заказа: «Я хочу кейс № 17, кейс № 3, и двадцать первый заверните мне тоже пожалуйста».

– 37 –

Успехов в продажах!

Центр экспертизы Windows Azure в России: azurehub.ru

А вы спокойны за ваши данные?

Microsoft Windows Azure — это: • Готовая надежная инфраструктура в облаке • Гарантия защиты данных от посторонних • Экономия в обслуживании системы • Хостинг Windows и Linux • Готовность к ФЗ-152

Практические приемы организации службы поддержки в условиях постоянных изменений Сергей Яковенко Руководитель ИТ-отдела в крупном российском холдинге

От ведущего: Здесь сейчас мы будем говорить о серьезных вещах – о том, как поддерживать то, что творческие люди «натворили». Вопрос, на самом деле, серьезный. Так как я – творческая личность, а Сергей представляет зону поддержки, наверное, я должен спросить: как ты к нам относишься? От докладчика: С большой любовью отношусь. Особенно утром, после очередного обновления, когда мои консультанты получают какой-то очередной запрос, открывают программу и… «Оп-па, она другая!…»

Меня зовут Сергей Яковенко. Я являюсь руководителем отдела поддержки пользователей в одном очень крупном российском производственном холдинге. Суммарно в наших системах на базе 1С сейчас работает свыше пяти с половиной тысяч пользователей. Мой отдел занимается поддержкой – где-то 500 активных аккаунтов на поддержке. Я попробую поделиться с вами своим опытом: что и как бывает, что как работает. И свой доклад начну не с тех тезисов, о которых рассказывали предыдущие докладчики. То есть, докладчики были нацелены на то, «как сделать» – как сделать качественно, красиво, как сделать хорошо. Я начну с того, что постараюсь ответить на вопрос: «что такое качество».

Качество проекта внедрения программного продукта

Я думаю, всем знаком «треугольник качества» – тройное ограничение ресурсы/время/деньги.

Вроде бы, все понятно. Правда, ожидание – такой «плавающий» фактор. Но, я думаю, если не у всех, то у многих были в практике такие проекты, когда пришли и за полгода внедрили автоматизированную систему на базе типового продукта. Чудесным образом бюджет был соблюден, сроки отклонились совсем ненамного, с ресурсами тоже вроде как угадали. Пришли к заказчику: «Вот, все получилось». Заказчик говорит: «О, все здорово!» Не верите? Ну, вообще-то, успешные проекты все-таки встречаются. А как часто происходит потом? Проект запускается в эксплуатацию, в этот момент мы подписываем контракт на ИТС и уходим. Проходит год. Мы возвращаемся к клиенту, потому что у нас заканчивается подписка ИТС, и говорим: «Ну все, у тебя льготный период закончился. Давай подписывать ИТС». И тут, внезапно, нам заказчик говорит: «Да, вообще-то, вроде бы система-то не очень. Внедренные отчеты не работают. Я был вынужден нанять двух местных программистов, которые мне дописывали что-то. У них тоже ничего не получилось. И, на самом деле, я сейчас уже готовлю бюджет на внедрение SAP. В общем-то, ИТС никакого не будет.»

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

Долгосрочная составляющая качества

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

Для меня самое понятное определение термина качество – это соответствие ожиданиям. Соответствие ожиданиям того, кто заказывал проект.

– 39 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Давайте попробуем задуматься, что же такое долгосрочная составляющая качества?

• Во-первых, результаты проекта востребованы и после окончания проекта – иначе, зачем мы его делали. Хотя бывают и разовые проекты, и не только в IT-отрасли.

• Во-вторых, результаты проекта приносят ценности в течение длительного времени – иначе, опять же, мы внедряем ERP-систему, мы внедряем учетную систему. Чем больше у нас данных в учетной системе, тем больше мы ее используем, тем больше результата она нам может дать. Соответственно, и наши результаты проекта должны быть долгосрочно востребованы.

• В-третьих, очень важный тезис – изменения не разрушают систему. То есть абстрактный пример, который я привел, когда пришел местный программист из соседней деревни, добавил новый документ «Планирование ремонта». 37 регистров на него написал. И внезапно у нас расползся БДР. Вот если мы так проводим изменения, тогда у нас система разрушается. Долгосрочного качества мы не достигаем.

• В-четвертых, опять же,мегаважный тезис – заказчик понимает и (важно!) принимает стоимость владения. Про термин «стоимость владения» у меня будет отдельный слайд, где более подробно расскажу, как я его понимаю.

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

Идешь к пользователю и спрашиваешь его:«оцени свою удовлетворенность по трехбалльной шкале – не доволен/так себе/доволен». Если все довольны, значит, все хорошо. Даже если система за год стала совершенно другой, но все довольны – это хорошо! Это значит, система живет, система развивается. Значит, раз у нас пользователь является ключевым индикатором, давайте попробуем задуматься: а что же заботит пользователя.

Что же заботит пользователя?

– 40 –

• Итак, первое. У нас может быть мегакрутая система. Но если я, как пользователь, в нее не могу зайти…Вот прямо сейчас мне потребовалось зайти в систему, и у меня это не получилось – мне такая система не нужна. Там может быть 37 панелей-индикаторов, красивые картинки, супер-интерфейс. Но если мне в нее не зайти, или я могу в нее зайти, но она мне не отвечает – такая система мне не нужна.

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

• Третье – тоже очень важное состояние пользователя: «Я знаю, что я знаю, как отразить операцию». Вот я с этого начал, что прошло очередное обновление и, внезапно, у документа «Перемещение товаров», которым я пользуюсь несколько раз на дню, изменилась форма. Мне нужно подумать, найти эти поля, включить голову, эмоционально напрячься… Но, когда такое происходит, я теряю уверенность, что завтра, зайдя в программу, я смогу отразить эту операцию. То есть, я перестаю быть уверенным в программе.

• Четвертое – это «прописной» тезис: «Я знаю, куда обратиться, если у меня что-то не получается, и уверен, что там мне помогут».

• Пятое – «Я верю отчетам системы и использую их в своей работе». Иначе для чего нужна система? Если я ей не верю или я ею не пользуюсь – тогда она для меня обуза.

• И, наконец, очень важная «фишка» – «В программе есть что-то лично для меня». Я общался с пользователями – и, в основном, конфликты с пользователями решаются таким образом – «Давайте мы что-нибудь для вас сделаем». Это не нужно воспринимать буквально, я не призываю делать из программы зоопарк. Можно просто рассказать, что мы это сделали для вас. На самом деле, это нужно было всем пяти с половиной тысячам, но мы каждому сказали, что это было сделано специально для него.

Сергей Яковенко

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

Доступность системы

• Еще одна такая прописная истина – обязательно должен быть документ DRP (DisasterRecoveryPlan), план восстановления – по-всякому можно называть. Это документ, где прописано, где лежит дистрибутив, где лежат архивы, какие особенности установки. Да, этот документ нужен только тогда, когда случилась авария. Но вот, не дай бог, она у кого-нибудь случится. Даже если вы, во время того, когда у вас упал сервер, будете лезть на интернет-сайт для того, чтобы скачать дистрибутив, а потом вспоминать, какую версию драйвера нужно установить – у вас прибавится два часа работы. А если ваша система высоко нагружена, и пользователи требуют, чтобы она работала, значит, вы на два часа отклонились от своих договоренностей.

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

Здесь, я считаю, бескомпромиссный слайд:

• Администратор у системы должен быть. Об этом написано везде. Приходите к заказчику и говорите там: «Системе нужен администратор, неважно, штатный это администратор или приходящий, но администратор должен быть. Причем он должен быть постоянный, и он должен быть обучен, он должен понимать, что он делает». Например, мы покупаем машину, мы на ней ездим. Если мы в нее не заливаем масло, мы едем первые 20000 километров хорошо, потом хуже, потом еще хуже… А потом нам выставляют счет на ремонт. Без администратора в нагруженной системе все тоже самое. Когда клиент пытается сэкономить на администраторе, здесь нужно просто прямо бескомпромиссно доказывать клиенту, что такого нельзя делать. Почему я считаю, что можно клиенту разъяснять необходимость привлечения администратора? Потому что раньше у меня была работа во франчайзинге, а сейчас у меня опыт работы со стороны клиента. И я, как клиент, вменяемый. Если мне нормально объясняют, зачем это надо делать (если мне приводят аналогию с машинным маслом), я начинаю понимать.

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

—— Вот смотрите, давайте на примере УПП возьмем. Там есть чудный механизм Профили доступа. Поставьте правило, что все пользователи работают на профилях. И этот список профилей более-менее ограничен.

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

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

Пищевая цепь потока информации

Дальше– более веселый слайд.

Вот мы работаем с информационными системами. У меня родилась такая картинка – «Пищевая цепь потока информации». Только я ее сейчас попробую рассмотреть с самого окончания этого потока.

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

Внимание! В информационную систему информация попадает с рук пользователей. Есть системы, которые сами снимают датчики (АСУТП) – например, проходы, чековая статистика и пр. Но, по большей части, в заполнении информационной базы участвуют пользователи. Ну а пользователи получают информацию из внешнего мира либо из внутренних процессов.

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

– 41 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 купок. Чаще всего, пользователь просто видит эти «часики», про которые – он уже знает, что нажми <Ctrl + Alt + Esc>(сними задачу) и запусти заново, и, может быть, все получится.

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

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

Работа в программе не должна быть обузой

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

• Ну и неинформативность сообщений тоже. У вас где-то там не хватает остатка… Где не хватает? Почему не хватает? Зачем?

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

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

А теперь, смотрите, вот мы научили кладовщика. Проходит четыре месяца. На предприятие приходит новый кладовщик. Этот кладовщик как-то с учетом в программе смог разобраться. Еще через четыре месяца приходит новый кладовщик. Как вы считаете, от кого он и что узнал? Правильно, чаще всего – от коллег. И очень хорошо, если коллега, который передавал ему свои знания, обучался. Еще ладно, если забыл. Но, все равно, главное, чтобы он обучался.

Иначе получается сломанная цепочка, в которой вообще ничего хорошего. Здесь изображена форма документа «Поступление товаров и услуг» из демо-версии последнего релиза УПП. Как вы думаете – сколько на этой форме элементов управления?

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

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

Кроме того, что у нас такой перегруженный интерфейс, есть еще пара немаловажных моментов:

• «Молчаливость» работы. Сейчас в управляемом интерфейсе при длительных операциях хотя бы крутится индикатор – идет заполнение книги по-

– 42 –

• Смотрим описание во встроенном помощнике: «Документ «Поступление товаров и услуг» служит для отражения различных операций по поступлению товаров. С помощью этого документа можно отразить такие операции, как покупка товаров, прием товаров на комиссию, поступление товаров и материалов в переработку, а также покупку оборудования». А теперь представьте, что я – новый кладовщик. И у меня приехала фура с чем-то. Мне это описание поможет?

• Да, есть описание системы УПП. Год или два назад в этом описании было пять книжек. Причем содержание этих книжек примерно такое же, как и встроенная справка.

Сергей Яковенко

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

Так вот, если вдуматься и посмотреть со стороны, – какие пользователи бывают и что они делают?

Обычный пользователь, который вводит первичную информацию,в своих взаимоотношениях с системой вводит 5-7 видов типовых операций ввода данных. Причем эти операции изо дня в день практически одни и те же. Отличаются только наименование контрагента, наименование номенклатуры, количество, сумма. Есть, конечно, 20% времени – когда он, действительно, отражает нестандартные операции, от них никуда не деться. Есть такие пользователи, как главный бухгалтер, например, у которых нестандартные операции встречаются еще чаще (например, выгрузка отчета – там постоянно надо какой-то анализ проводить). Но все равно – 80% информации в системе дают пользователи, которые в своей жизни используют 5-7 видов операций. Как нам упростить им жизнь? Ответ банальный. Для них нужно написать инструкцию.

Но какие инструкции мы пишем? Чаще всего мы пишем инструкции по доработкам – то, что мы доделали. Либо инструкции, очень похожие на описание.

Какими бывают инструкции

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

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

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

В итоге я заставил написать функциональную инструкцию. Она заняла два листа. Эта инструкция отвечает на простой вопрос: как завести табель в систему – без каких-либо отклонений. Просто десять шагов: открыть/ввести/закрыть. Я ее беру, по пунктам делаю – и все получается!

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

Требования к функциональной инструкции

Я выписал, как я понимаю требования к функциональной инструкции:

Техническая инструкция – очень полезный документ. Я ни в коем случае не умаляю его достоинства. Потому что когда мой консультант с поддержки пытается разобраться, что и как работает в системе, его спасает только техническая инструкция. Но, когда пользователь, которому нужно что-то сделать, смотрит техническую инструкцию, для него то, что там написано – «ни о чем».

Я приведу пример. У нас на предприятии внедряется новая HR-система (не 1С), и она перешла ко мне в отдел на поддержку. Плюс (у нас изменился немножко процесс) я должен забивать теперь два раза в месяц табель учета рабочего времени. Я честно, как самый обычный пользователь, прогулял все обучения. Я же айтишник, я же ого-го сколько этим занимаюсь!!! Что же, я не разберусь, как табель завести?

– 43 –

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

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

INFOSTART JOURNAL №2 НОЯБРЬ 2013 кто у меня как работал. Если я, например, только что вернулся из отпуска и мне еще ничего не рассказали, документов/журналов никаких не предоставили – я табель не забью. Мне нужно сначала посмотреть, кто как являлся(получить сначала эту информацию).

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

ServiceDesk – служба поддержки пользователей Наша служба и опасна и трудна, и на первый взгляд как будто не видна.

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

• Разбор возможных ошибок лучше в конце, по тексту только наиболее вероятные ошибки, с указанием, что делать. Все отклонения и работу над ошибками лучше сместить на конец инструкции. То есть, когда мы берем инструкцию от СВЧ-печи – у нас там в конце табличка: «У вас не зажегся индикатор? – сделайте вот это», «У вас не открылась крышка? – отвезите ее в сервис».

Функциональная инструкция – гарантия корректной работы пользователей

Вот смотрите, сейчас кто-то скажет: «Сейчас нам еще один вид документа писать… Это долго». На самом деле, это три листа максимум. Даже двух листов будет достаточно. Обычно написание подобной инструкции занимает не более 2-х часов. 20 функциональных инструкций (кейсов) на достаточно крупное предприятие, я вас уверяю, – это хороший, более чем достаточный объем. В итоге – это 40 часов. Это не такой большой бюджет для гарантии того, что пользователи будут делать все единообразно, и будут вводить информацию единообразно.

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

– 44 –

• ServiceDesk предназначен для решения вопросов пользователей, связанных с работой в ИТ системах. Давно слышал такую поговорку: самый лучший айтишник – это тот, которого никто не знает. На самом деле, так оно и есть, потому что призвание службы ServiceDesk (службы помощи клиента) – это помочь пользователю. Это, как у скорой помощи, либо как у пожарных. Например, мы курим в кровати, и из-за нас случился пожар. И да, мы знаем, что это мы виноваты, но мы звоним в пожарную службу, чтобы нам помогли. И пользователь точно с таким же настроением обращается в поддержку. Поэтому, когда поддержка начинает говорить: «У-у-у… Что ж вы тут наделали!» Пользователь начинает думать: «Слушай, ну я и так знал, что я тут что-то наделал! Я тебе что позвонил-то, что обратился?» Вот здесь очень важно понимать, что любой ServiceDesk предназначен для того, чтобы помочь. Потом скорректируем. Потом расскажем, где он был не прав. Потом там все сделаем. Но сначала помочь.

• Это книжный тезис: основной показатель качества работы службы – отношение количества запросов пользователей, выполненных в срок к общему поступившему количеству запросов.

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

Сергей Яковенко

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

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

Когда будет большой объем, посмотрите на хорошие системы с префиксом ITIL, еще что-то… Да, там есть много вкусного, много хорошего, но не нужно начинать с них сразу. Там может случиться такая же ситуация, что открываешь форму документа – и теряешься.

• Договоритесь с Заказчиком о SLA (нормальный срок от 1 дня, если это не вопрос доступности). Никогда не поддавайтесь, и заказчики – никогда не требуйте от исполнителя моментальный срок реакции. Принцип SLA, описанный в ITIL, звучит так: мы гарантируем, что 95% ваших запросов будут решены в срок. Допустим, срок один день. То есть, я гарантирую, что в течение одного дня решу 95% запросов. Но, когда мы начинаем требовать, что все запросы должны решаться за один час – это может привести к тупиковой ситуации. Например, у нас на поддержке 100 пользователей и у нас есть 10 консультантов – и тут, по не зависящим от техподдержки причинам, все эти 100 пользователей нам послали запрос. 10 консультантов не хватит. Поэтому со стороны исполнителя абсолютно нормально выдвигать несоизмеримые бюджеты под требование срока решения 1 час. Просто об этом нужно разговаривать. Это понимают. Кто не сталкивался – понимает не сразу. Но, тем не менее, это аргументировано.

Организация работы службы сервис-деска ска

На что обратить внимание при создании сервис-де-

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

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

• Далее необходимо определить метод хранения запросов пользователей (Дата обращения, Инициатор, Содержание вопроса, Дата передачи ответа, Исполнитель, Краткое содержание ответа). Когда я два года назад пришел в компанию – сервис-деск работал на Outlook. Отлично работал. Ничего не надо было. На сервис-деске было пять специалистов, и количество запросов в день не превышало 20-50. Обычный Outlook с системой флажков работал идеально. Плюс один запрос, который это все вытягивал в базу данных. На самом деле Excel тоже будет работать хорошо. Соизмеряйте инструмент с объемом обрабатываемой им информации. Не нужно сразу вдаваться в поиск инструмента.

Процесс изменения и эксплуатации должен быть разделен Самый последний тезис: «Разделяй и властвуй»

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

– 45 –

• Из этого следует простой тезис: С точки зрения владельца бизнеса, изменения – это капитал, а поддержка – это текущая деятельность. Это к разговору о том клиенте, с которого я доклад начал, который систему у себя внедрил, год с ней мучился и теперь уже не хочет на ней работать. Мы к нему придем через год и спросим – «А сколько у тебя стоимость владения?» Он скажет – «N-цать сотен тысяч». А начнем разбирать

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Всегда помнить, для кого разрабатываете систему или пишете инструкцию: техспециалист или пользователь

– он из этих десятков или сотен тысяч большую часть потратил на то, что ему там какие-то доморощенные программисты что-то меняли. Хотя, он-то хотел поддержку, а ему что-то меняли. Вот здесь происходит разрыв сознания, и пока мы этот конфликт заказчику не объясним – мы никогда не сможем выстроить ни эксплуатацию, ни изменения. Это постоянно будет «тяни-толкай». Я рекомендую разделять поддержку и изменения на уровне бюджетов, на уровне контрактов. Франчайзерам – тоже советую.

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

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

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

Ключевые факторы изменений

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

В заключение • Договориться с Заказчиком о минимальном сроке появления изменения в продуктиве и завяжите обновление на технологические окна (лучше не брать меньше недели)

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

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

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

Что учитывать при разработке

При развитии готовой системы следует:

Я не рассмотрел только два:

• «Я верю отчетам системы»

• «В программе есть что-то лично для меня». К сказанному еще хочу добавить:

• «Нет никакого секретного ингредиента, также, как и волшебной палочки» – полностью к тезису присоединяюсь

– 46 –

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

Кейсы проектов как инструмент успешного запуска автоматизированных систем Александр Тарасинский Руководитель крупных проектов в Украине, России, Казахстане и Белоруссии

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

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

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

Руководителям проектов, бизнес-аналитикам, программистам. Что такое кейс?

Впервые понятие кейса было введено Гарвардской школой бизнеса около 100 лет назад. Кейс – это реальный случай, на котором разбираются теоретические идеи для поиска лучшего решения. Метод кейсов успешно применяется в обучении студентов для выработки практических навыков решения бизнес-проблем. Идею кейсов в виде отчетов клиентам развила компания McKinsey, у которой были тесные связи с Гарвардской школой бизнеса. Подход консалтинговой компании McKinsey к управлению проектами

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

Чем известна компания McKinsey? Это одна из самых именитых консалтинговых компаний в мире. Само понятие «управленческий консалтинг» появилось с подачи McKinsey. Специализация Компании – стратегический бизнес-консалтинг. Клиентами компании являются не только ведущие компании мира, но и правительства различных стран. Если говорить о масштабе проектов McKinsey, то результатом завершенного проекта в январе 2013 года стали практические рекомендации правительству США сэкономить 1 трлн долларов за счет применения системного подхода в развитии инфраструктуры.

– 47 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 В чём же секрет McKinsey? Это великолепно подготовленные консультанты, структурированный подход к разрешению проблем и бережное отношение к управлению знаниями. Карта памяти 2. Секрет McKinsey.

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

всех компонентов проблемы, начиная «с вида сверху» и продвигаясь всё ниже. Составление логического дерева выполняется в соответствии с принципом MECE: все ветви одного уровня дерева должны взаимно исключать друг друга и одновременно совместно исчерпывать описание проблемы на одном уровне иерархии. При создании логического дерева, нужно понимать, что выбранный способ построения дерева повлияет на видение ключевых проблем Клиента и определит вопросы, на которые нужно будет найти ответы для подтверждения гипотезы решения проблемы. За годы работы компания McKinsey разработала множество логических деревьев – фреймворков, которые помогают описать различные бизнес-ситуации. Фреймворки бизнес-ситуаций

Фреймворк можно представить в виде структуры, на основе которой выстраивается модель решения проблемы. Использование фреймворков позволяет применять лучшие практики отрасли, даже если ранее Консультант не знаком со спецификой работы Клиента. Вкратце рассмотрим фреймворк «Движущие силы». К нему прибегают в самом начале работы над проектом для выявления ключевых факторов, влияющих на бизнес Клиента. Анализируются позитивное и негативное влияние факторов на уровне предприятия, а также сложившаяся практика ведения бизнеса в отрасли. Карта памяти 4. Фреймворки в McKinsey.

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

2. необходимо усиливать свое мышление с помощью структурирования.

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

При рассмотрении структурированного подхода, для применения в кейсах проектов 1Синтересен инструмент «логическое дерево» и фреймворки бизнес-ситуаций. Инструмент «Логическое дерево»

Чаще всего для структурирования используют инструмент – логическое дерево: иерархический список

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

– 48 –

Александр Тарасинский

Кейсы проектов как инструмент успешного запуска автоматизированных систем

Поиск решения

Карта памяти 6. Приёмы из Теории решения изобретательских задач.

Карта памяти 5. Поиск решения по McKinsey.

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

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

Выдвижение гипотез для поиска решений применяют учёные физики. Начиная путь решения проблемы с одного феномена, взятого почти наугад, учёные выводят гипотезу – предположение о возможной причине существования данного факта. Далее, исследователи, из гипотезы логически выводят неизбежные последствия: ЕСЛИ гипотеза верна, ТОГДА логически должен так же существовать другой факт. И с помощью таких логических выводов открывается целый спектр других явлений.

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

ТРИЗ разработана нашим соотечественником Генрихом Альтшуллером во времена СССР. До изобретения Теории процесс изобретательства (а фактически между запуском проекта и изобретательством можно провести аналогию) выглядел как перебор всех возможных и невозможных вариантов с целью найти решение.

Конечно же, ТРИЗ можно применять для решения не только технических задач. Генрих Альтшуллер применял ее и в своей личной жизни. Например, у него в 50-е годы возникла проблема с работой. Так как он сидел в Воркуте по обвинению в продаже изобретений заграницу и вышел на свободу по амнистии, то далеко не каждая организация была готова принять его к себе на работу. Поэтому он сформулировал свою проблему таким образом – «как работать, не работая». И нашел ответ – стать писателем. В результате он стал писателем-фантастом и издавал свои книги под псевдонимом Альтов. Сбор фактов для подтверждения и опровержения гипотез

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

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

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

– 49 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Управление знаниями в McKinsey

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

Карта памяти 7. Управление знаниями в McKinsey

Если проследить путь IBM от идеи к представлению фреймворков проектов, то он занял более 30 лет, начиная от появления понятия «реляционной базы данных» Эдгара Кодда.

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

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

Кейс (отчет) по McKinsey = (Логическое дерево + Фреймворк) + Решение + Факты.

Кратко можно записать этот путь так: понятие «реляционная база данных» -> фреймворк архитектуры предприятия -> понятие «OLAP» -> внедрение OLAP проектов -> информационный фреймворк -> индустриальные модели. Карта памяти 8. Путь IBM.

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

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

Компания McKinsey активно использует кейсы, фреймворки и лучшие практики для сокращения сроков запуска проектов и повышения качества предлагаемых управленческих решений. Решение IBM для IT-проектов

Теперь предлагаю рассмотреть развитие идеи кейсов на примере решений IBM по запуску проектов Бизнес Аналитики (BI). Сегодня IBM Software Group предлагает своим клиентам разработанные индустриальные модели – IBM Industry Models. Приобретая индустриальную модель, клиент может быть уверен, что

– 50 –

Александр Тарасинский

Кейсы проектов как инструмент успешного запуска автоматизированных систем

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

IBM предлагает своим клиентам оптимальную структуру BI-хранилища с учетом лучших практик отрасли. Причем предлагаемые модели не являются статичными и регулярно обновляются 1 раз в 12-18 месяцев. Для каждой отрасли тщательно проработана структура данных и подготовлен набор аналитических показателей с измерениями. По утверждению IBM, цена проекта, который запускают с использованием предлагаемых индустриальных моделей, будет снижена вдвое. Рисунок 2. Программа IBMm1 с загруженной моделью для Розничного сектора.

Рисунок 3. Фреймворк Закмана.

Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации. Ну и напоследок, думаю, что интересно было бы узнать цену IBM за индустриальные модели. Знаю, что модель для розничных предприятий обойдется где-то в районе 300 тыс. Евро. Резюме

Кейс по IBM = Фреймворк с готовым набором аналитических показателей и измерений.

Компания IBM активно использует кейсы с внедрением лучших практик и на их основе создаёт фреймворки для сокращения сроков запуска проектов и повышения качества предлагаемых IT-решений.

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

Фреймворк Закмана позволяет свести сложные архитектурные проблемы корпоративных информационных систем к ответам на простые вопросы: Кто, Что, Когда, Где, Зачем и Как. Интересной стороной фреймворка является возможность рассмотреть архитектуру разрабатываемого решения не только с точки зрения технологии, но и точки зрения бизнеса. Фреймворк представляет архитектуру предприятия с точки зрения генерального директора, менеджера, архитектора, разработчика и технического специалиста. Описательная часть фреймворка содержит сведения о бизнес-процессах предприятия, представлена структура данных и, даже, описывается размещение оборудования.

Кейсы проектов для 1С

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

1С:Профкейс позиционируется как свод знаний, который может использовать любая компания-партнер 1С в своей работе. 2/3 информации посвящено работе компаний Франчайзи, и оставшаяся часть – проектному управлению. Работу над этим продуктом 1С ведет с 2006 года. К сожалению, хоть 1С и задекларировала планы по размещению в ПрофКейсе сведений об успешно завершенных проектах, но на текущий момент (май 2013) эта информация отсутствует.

– 51 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Рисунок 4. Страница кейсов на сайте 1С:Консалтинг.

Карта памяти 9. Управление проектами в 1С.

Для руководителей проектов могут быть интересны разработанные 1С технология быстрого результата (ТБР), стандартного и корпоративного внедрения.

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

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

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

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

Какой может быть результат?

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

Карта памяти 11. О сайте 1С:Консатлтинг.

2. фреймворки для работы над проектами с учётом отраслевой специфики (например, УПП для пищевой промышленности); 3. лучшие отраслевые практики. Фреймворк кейса проекта

Во-вторых, информация о кейсах не обновляется с 2011 года.

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

– 52 –

Александр Тарасинский

Кейсы проектов как инструмент успешного запуска автоматизированных систем

Карта памяти 12. Структура кейса 1С.

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

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

Карта памяти 15. Пример кейса проекта 1С для внедрения в торговой компании с точки зрения Архитектора.

Карта памяти 13. Вариант кейса 1С.

Логистика

1С

Примеры кейсов реальных успешных проектов

А теперь хочу представить части реальных кейсов проектов в Торговле, Логистике и Производстве с точки зрения Архитектора проекта и Бизнес-аналитика.

Проект по запуску оптово-дистрибуционного склада стал серьёзным вызовом для компании. Проблема в запуске склада состояла в том, что в типовом продукте «Управление складом» была предусмотрена только схема работы оптового склада, а особенности работы дистрибуционного склада не были учтены. В результате анализа было выявлено ограничение, которое препятствовало сбору грузов для доставки по Москве и области. Т.к. склад был многоярусным, то ограничением оказалась скорость перемещения паллет с верхних ярусов на нижние ярусы. В результате, внедряемое решение пришлось дополнить схемой группировки мелких заказов по автомобилям и размещать паллеты на нижнем ярусе склада согласно планограмме с учётом частоты востребованности товара и среднего размера заказа. Карта памяти 16. Пример кейса проекта 1С для внедрения WMS-системы с точки зрения бизнес-аналитика.

Карта памяти 14. Примеры кейсов.

– 53 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Источники информации:

Производство При внедрении УПП на предприятии, которое занимается производством продуктов питания, хочу рассказать об одной особенности работы завода. Это учёт движения сырья по складам и в производстве по срокам годности. Таково требование законодательства. До внедрения УПП эта информация велась или в Excel или на бумаге. Когда обратился за консультацией в три компании франчайзи, то одновременно все консультанты ответили, что в 1С запуск посерийного учёта на большом предприятии нереально внедрить. У меня это работает. Вполне может быть, что если в распоряжении команды при запуске проекта под рукой будут кейсы с реальными примерами внедрения такого учёта, это поможет принять обоснованное и устраивающее Клиента решение. Карта памяти 17. Пример кейса проекта 1С в производстве с точки зрения бизнес-аналитика.

1. Инструменты McKinsey. Лучшая практика решения бизнес-проблем | Итан Расиел и Пол Фрига

2. Метод McKinsey. Использование техник ведущих стратегических консультантов для решения личных и деловых задач | Итан Расиел 3. Золотые правила Гарварда и McKinsey. Принцип пирамиды в мышлении, деловом письме и устных выступлениях | Барбара Минто 4. Цель. Процесс непрерывного улучшения | Элия Голдратт, Джефф Кокс

5. Найти идею. Введение в ТРИЗ – теорию решения изобретательских задач | Генрих Альтшуллер 6. Вебсайт IBM. Introduction to IBM Industry Models 7. 1С: Консалтинг

8. 1С: Технология быстрого результата

9. Курс ИТРП «Как избежать ошибок на проектах»

10. Инфостарт. Статья «Как не нужно запускать проекты»

Заключение Считаю, что за последующие 25 лет технологии в бизнесе будут кардинально меняться. И определяющую роль будут играть автоматизированные системы. Произойдет качественный сдвиг в сфере автоматизации предприятий от профессии программиста в сторону бизнес-архитектора. И весьма вероятно, что на фоне стандартизации условий ведения бизнеса мы придём к конкуренции не предприятий, а конкуренции ИТ-систем. Чем более крутая ИТ-система установлена, тем большие возможности бизнесу она может представить в плане скорости выполнения операций, экономической эффективности и т.д. Взять хотя бы отрасль логистики. Уже много лет на рынке доступны решения по полной автоматизации складских операций: когда без участия человека в складе происходит движение паллет с помощью роботов. Собранные грузы могут с помощью специальных конвейеров загружаться в машины. Автопроизводители готовят технологии управления автомобилем без участия человека.

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

– 54 –

Практика централизации управления информационными базами и интеграционными процессами Михаил Харитонов Директор компании 2iS, автор Конвертации данных

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

Михаил Харитонов (http://www.2is.ru/) – эксперт по системной интеграции, директор компании 2iS, экс-руководитель направления интеграции прикладных решений компании 1С, автор Конвертации данных, стандарта CommerceML2, разработчик технологий интеграции 1C:Предприятия с другими системами, руководитель проектов автоматизации управленческого учета и консолидации холдингов X5RetailGroup, АвтоМир, Tez-Tour, и других.

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

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

7. Рассмотрим примеры крупных проектов, выполненных нашей компанией с применением данных практик.

8. И – два слайда про перспективы.

План доклада:

1. Несколько слов о себе и компании 2is. Чем занимаемся.

2. Как мы понимаем централизацию управления, как с этим связана SOA (сервис-ориентированная архитектура). Для кого это актуально.

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

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

5. Немножко углублюсь в теорию – благодаря чему достигнуты такие результаты. Вы увидите, что в основе централизации лежит, по сути, новая парадигма сервис-ориентированного программирования. Расскажу о ее: —— Концепции

—— Преимуществах

—— Архитектуре (на пальцах)

– 55 –

Личные достижения Немного о личных достижениях.

• Четыре года работал в компании 1С в должности руководителя направления интеграции прикладных решений – с 2000 по 2004 год.

• Собственноручно разработал «Конвертацию данных» – обе редакции. Первую – на версии 7.7 (в 2001 году), и вторую редакцию – на версии 8 (в 2003 году). Моим непосредственным руководителем был Сергей Нуралиев. В 1С у меня были достаточно креативные задачи – много изобретать, придумывать… Как наставник, как постановщик верхнеуровневых задач выступал Сергей Нуралиев.

• Моей ежемесячной обязанностью было наполнять диск ИТС различными универсальными обработками.

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Вы можете видеть на ИТС написанный мною «Универсальный бухгалтерский отчет для 7.7»,

А о нашем продукте, в котором реализованы лучшие из практик, о которых я буду сегодня рассказывать – «2is:Интеграция» вы можете узнать из рекламной листовки, на сайте www.infostart.ru и на сайте www.2is.ru.

—— «Универсальный журнал документов для 7.7»,

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

—— «Универсальные подбор и обработка объектов для 7.7 и для 8.х»,

—— «Универсальный обмен данными в формате XML», —— Стандарты обмена CommerceML (2000 год – xdr, 2003 года – xsd).

—— Это сервис-ориентированная архитектура, о которой я еще расскажу

• Также мною был разработан механизм типовых бухгалтерских операций для «1С: Бухгалтерия 8»,

—— Это экстремальное программирование (кто не знает – экстремальное – не от«экстремальные виды спорта и высокий риск», а от слова «Экстремумы», то есть – максимумы)

• механизм HRM-анкетирования в ЗУП, • и работа через интернет со штрих кодами в УТ.

—— Нам очень нравятся практики парного программирования. Хотя часто с большим трудом удается заставить программистов работать парами. Они сопротивляются, но эффект очень хороший. Парное программирование – это когда два человека сидят – один пишет код, другой проверяет и делает замечания. Вместе они решают какую-то практическую задачу для клиента за деньги клиента. Результаты выше всяких ожиданий.

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

• Отдельный предмет гордости – разработанная мной система автоматизированного тестирования платформы, интегрированная с базой «Синтакс-помощника».

—— Конечно же, Agile – это гибкая методология разработки ПО, которая связана и берет свои истоки у Кайдзен (японской технологии о бережливом (Lean)-учете и производстве). Сталкивались мы с «бережливым производством» при автоматизации производственных предприятий. Кайдзен– это непрерывное совершенствование путем устранения «муды» («Муда» – по японски – потери). Целевая философия. Кто заинтересуется – почитайте Википедию.

О компании 2is • Компания образовалась в 2004 году. Мне не хватало границ в 1С, чтобы быстрее развиваться – какие-то догмы сдерживали, поэтому я решил заняться разработкой самостоятельно.

• Компания 2is специализируется на крупных проектах, по тематикам —— «Интеграция»,

Что такое централизация управления? Как она связана с SOA (сервис-ориентированной архитектурой)? Что такое SOA?

—— «Консолидация»,

—— «Управленческий учет», в том числе и по МСФО.

• По правилам конференции реклама программных продуктов запрещена. Я буду в основном рассказывать об инновациях в нашей компании – лучших практиках и выполненных проектах.

Из Википедии: SOA (сервис-ориентированная архитектура) – это модульный подход к разра-

– 56 –

Михаил Харитонов

Практика централизации управления информационными базами и интеграционными процессами

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

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

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

• При такой практике, вроде бы все хорошо, но: возникает «зоопарк» систем, которыми необходимо управлять.

• Функцию управления как раз и берет на себя центральная управляющая база данных – овал в центре скриншота:

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

Кто заинтересован в централизации и в SOA?

• Часто бывает сейчас, что компания строит какой-то монолитный программный комплекс под себя, под заказ – например, это УПП (переработанная, доработанная ERP система).

• И вот тут возникают какие-то потребности, выявляются узкие звенья, что у нас склад не очень хорошо работает: требуется более высокий уровень сервиса – радио терминалы, ячеистый учет, автоматическая логистика, транспортная логистика… Разросся IT-отдел – им тоже надо управлять.. Для налаживания связей с клиентами есть потребность в развитии CRM-контура… Конечно же, и владельцы бизнесов и IT-директора понимают, что более дешевый и быстрый результат можно получить, покупая законченные прикладные решения, которые направлены на решение конкретных задач. Причем, они руководствуются в своем выборе отзывами, принципом «Лучший в своем роде», ориентируются на известного вендора, который специализируется на том или ином. Результат получается более эффективным, чем самостоятельное доращивание своей могучей основной ERP-системы.

У компании 2iS большой опыт – мы такие управляющие системы (базы) уже делаем, по сути, последние лет шесть. Сначала мы делали такие решения для конкретных заказчиков. Сейчас «2is:Интеграция» – это тиражное решение (мы начали его продавать) – оно с нуля переписано на управляемом приложении. Авторы (основные разработчики) этого решения – ваш покорный слуга и системный архитектор нашей компании Старых Сергей (автор подсистемы «Инструменты разработчика»), работаем «плечом к плечу» уже более пяти лет.

Манифест SOA

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

– 57 –

Она постулирует, что:

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

• «интероперабельность» – способность к взаимодействию систем – важнее, чем какие-то разовые интеграции, разработанные специально,

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Чего нам удалось добиться? Чем мы научились управлять централизованно из одной точки (из одной базы) – подключаясь к другим системам и заставляя их работать в едином «оркестре»?

• Совместно используемые сервисы важнее целевых реализаций,

• в основу SOA положен важный и понятный принцип – «Гибкость важнее оптимизации». Конечно же, вроде тут очевидно: разработчики сначала обеспечивают максимальную функциональность, должны стараться предоставить все удобства, а потом заниматься улучшением производительности и оптимизацией,

• Эволюционное улучшение важнее достижения изначального совершенства.

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

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

Мировая практика. Мы, конечно же, рассматривали различные западные решения, особенно когда планировали наш продукт уже в тираж. Был проведен анализ существующих решений на рынке: • IBM WebSphere

• Microsoft BizTalk Server

• Software AG webMethods

• Oracle Enterprise Service Bus • SAP Net Weaver

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

– 58 –

• Управление обменом данными во всех его интерпретациях:

—— С использованием правил конвертации, разработанных в конфигурации «Конвертация данных» \ Без использования правил конвертации – для одинаковых конфигураций распределенных баз данных.

—— С использованием узлов планов обмена \ Без использования узлов – например, динамическими выборками документы за месяц с отбором по определенному складу или юр. лицу. В центре выполнили все настройки – обмен заработал на периферии («Интеграция» позволяет выстраивать сеть из распределенных управляющих инфосистем). Еще раз хочу отметить, что модификации управляемых конфигураций не требуется, не требуется их снимать с поддержки,все настраивается во внешней управляющей базе «Интеграции». Именно в эту базу импортируются xml-правила для конвертации данных при обмене, она также содержит в себе универсальную обработку обмена, которая по расписанию запускается в управляемых базах, заставляя их выгружать данные, либо друг для друга, либо интеграция работает в режиме «Шина», то есть закачивает в себя все данные и внутри диспетчеризует – кому какой объект раздать. Масштабирование достигнуто серьезное. На ряде проектов удалось обмен ускорить и заставить работать так, как требовал бизнес. Например, на проекте «Автомир» порядка 45 дилерских центров в разных городах России и СНГ. Центральная база – Финансы и управленческий учет. Все филиалы со своими многочисленными базами разных конфигураций 1С и не только 1С. Автосервис с учетом запчастей работает, кафе при нем, продажа подержанных автомобилей, страховщики тут же сидят, гаишники… У всех из них свои базы и все это консолидируется в центральной базе. Руководство сказало – с каждым филиалом цикл обмена хотим 5 минут. Результат был достигнут таким образом, что все данные со всех точек сначала собираются в некий «шлюз», представляющий из себя N справочников одинаковой структуры для промежуточного хранения

Михаил Харитонов

Практика централизации управления информационными базами и интеграционными процессами

XDTO-объектов – никаких блокировок при обмене! Потом отдельные параллельные задания (для удобства понимания можно сказать «регламентные задания») принимают (записывают по таблицам) данные разных типов с разной периодичностью. То есть,мы разделили приемку /и быструю раздачу данных филиалам,и уже обработку/подкачку данных в центре из промежуточного хранилища (шины). Понятно, что регистр бухгалтерии – не резиновый. 40 параллельных пользователей он никогда не потянет. У него архитектура такая…

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

• Управление рассылками отчетов

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

—— Режим «дозакачки» больших пакетов – продолжение загрузки с места остановки в случае прерывания. Допустим, мы зарегистрировали все документы за месяц, чтобы их перекачать, на ночь оставили – 3 Гб закачалось – в 2 часа ночи сервер перезагрузился (забыли учесть, что в это время резервное копирование идет средствами 1С), поэтому режим дозакачки в этом плане очень помогает. Сервер восстановился – и, с того места, где процесс прервался – он снова продолжается. К утру все документы закачаны.

• SMS и e-mail оповещения

—— Мониторинг объектов инфобаз – информирование об изменениях ключевых объектов.

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

—— Транспортный режим обмена – Интеграция выступает как шина и маршрутизатор для объектов данных.

• Управление любыми прикладными обработками данных в инфобазах

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

—— Мониторинг \ Протоколирование \ Продолжение с места остановки в случае сбоя. Центр управления произвольными прикладными обработками подключается к нужной базе, запускает каждую обработку по расписанию,мониторит ее, протоколирует результаты и выполнение, продолжает ее действие с места остановки в случае сбоя. Есть возможность

—— Произвольные условия контроля – рассылки при возникновении определенных условий. Например, подключились к базе, проверили просрочку по договорам – нерадивым клиентам разослали SMS. У нас самих в 2is это тоже используется, я всегда всем клиентам показываю: вот, смотрите, у меня на телефоне SMS – сотрудники вовремя ежедневные (еженедельные) отчеты не прислали… Причем, сначала обязательно приходит предварительное напоминание, потому что сотрудник, конечно, может просто забыть. То есть, сначала приходит SMS, которое напоминает, а потом уже следующее, через час, сообщает о том, что начислен штраф.

Настройка сервисов-обработчиков входящей почты (примеры tasks@2is.ru, arh@2is.ru, docs@2is.ru ). Для примера – как настроено у нас в 2iS:

По каждому письму, полученному на ящик tasks@2is.ru система «Интеграция» автоматически создает в базе ведения учета задачи, формирует документы типа ТЗ. При этом заполняет реквизиты из письма. В письме можно написать «Проект = УТ, Кому = Харитонов» и распознанные системой значения из письма будут записаны в соответствующие объекты. Входящие письма на ящик arh@2is.ru автоматически помещаются в «1С:Документооборот». Направил файл Excel на такую почту – а он в Документооборот записался.

Входящие письма на ящик docs@2is.ru – записываются в виде html в нашу базу. Очень удобно, html закачивается с картинками, потом в базе это можно использовать.

– 59 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Интеграция импортирует настройки регламентных заданий любых инфобаз 1С и централизованно контролирует их работоспособность, разделяя разные уровни аварийных состояний при этом (разные списки адресатов уведомлений в зависимости от критичности проблемы и важности задания) • Единый центр контроля производительности инфобаз —— Регулярные тесты и замеры (открытие форм, запись объектов, проведение и т.д.)

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

Клиентам мы позиционируем наше решение как новый уровень информационной безопасности. Судите сами:

• Единый центр администрирования инфобаз

—— Встроенная консоль серверов 1С, из которой можно регистрировать все нужные объекты инфраструктуры 1С (центральные серверы, кластеры, инфобазы)

• Единый центр управления пользователями информационных баз. Например, администратору сказали: «У нас новый сотрудник, его нужно подключить к этой базе, к этой и этой». Этого сотрудника заводят в едином центре, галочками там же роли ему указали, какие у него есть в каждой базе – все! Интеграция подключилась к базам, информацию по новому пользователю в них добавила. Сотрудник уволился,его отключили только в центральной управляющей базе «Интеграции» и сразу во всех базах он утратил свой доступ. Часто же,как бывает, забыли, сотрудник – как активный пользователь в базе остался… Плюс этот сервис проверяет ежедневно пароли,нету ли пользователей без паролей.

—— Выгрузка конфигурации \ Загрузка и Обновление конфигурации из файла или хранилища —— Выгрузка базы —— Управление балансом между регулярностью выполнения регламентных заданий и максимальной нагрузкой на сервер

• Единое хранилище журналов регистрации информационных баз

—— Из ключевых инфобаз регулярно порциями выгружается штатный (платформенный) журнал регистрации и загружается в единое хранилище, специальная отдельная база логов, в которой все журналы записываются в специальной структуры регистр сведений. Можно посмотреть журнал регистрации не по одной базе, а по нескольким информационным базам, причем быстро, так как это реляционная таблица регистра сведений. То есть, если у нас между базами выполняется обмен и случилась коллизия – объект улетел из одной базы, а в другую не прилетел… Почему? Начинаем разбираться: смотрим единый лог,в этой базе изменен – выгружен, в другой базе тоже изменен. Возникла коллизия, столкнулись: приоритет настроен в приемнике выше, значит, действительно объект не заместился, остался в своем старом состоянии.

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

—— Отчет по истории изменений и перемещений конкретного объекта в разных базах • Контроль аварийных состояний регламентных заданий инфобаз. Управляется централизованно.

– 60 –

Михаил Харитонов

Практика централизации управления информационными базами и интеграционными процессами

Новая парадигма сервис-ориентированного программирования

Здесь видны «всплески» – иногда сервер перегружен (по оси Y – это миллисекунды). Можно настроить автоматическое оповещение, если график выходит за рамки настроенной вилки значений.

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

Режим регламентных заданий, тем не менее,в этом отчете тоже поддерживается. То есть, можно импортировать из любых баз их регламентные задания и переключать их, и ими управлять уже из единого центра. Плюс – разбиваем все задания по ответственным, например Истошина Мария (это наш HRM-менеджер), отвечает за задания по рассылкам, предупреждениям, контролю сотрудникам – она получает сообщения, если задания не работают или выдают ошибки в процессе выполнения. Тогда она «разыскивает разработчика» и требует разобраться.

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

Что это такое? Я думаю, что через пару-тройку лет (5-10 лет – примечание редактора)мы все придем к версии 1С-10 и она будет построена именно по такому принципу. Давайте рассмотрим суть новой парадигмы на пальцах и в картинках:

Благодаря чему это все возникло? Перейдем к теоретическим аспектам.

– 61 –

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

—— Гранулой является одна функция («алгоритм», «сервис»). По-старому это называлось «Алгоритмы», сейчас у нас этот справочник называется «Сервисы». В качестве элементов справочника – максимально подробно декларативно описанный реляционными средствами программный код (в таблицах СУБД).

• Входные \ выходные параметры

• Внешние ссылки на объекты определен-

INFOSTART JOURNAL №2 НОЯБРЬ 2013 ной базы (внутренние параметры – константы сервиса)

• Ссылки на другие, используемые в программном коде сервисы – как одна функция вызывает эту функцию, та ищет еще какую-то (вплоть до рекурсии (циклической рекурсии)… Здесь, как вы понимаете, это все храниться в виде ссылок – в справочнике один сервис вызывает второй, то есть получаем полноценную реализацию структуры подчиненности функций

• Ссылки на используемые сервисные объекты (Запросы, СКДи другие). Запросы хранятся в отдельном справочнике с параметрами, схемы компоновок во втором, схемы XML в третьем и так далее – на одном из следующих слайдов будет (целая простыня из текущих, существующих в системе сервисных типов), то есть того, что в одной базе хранится централизованно, но может исполняться и ипользоваться в любых базах при помощи специального мобильного движка.

• Хранимые централизованно сервисы (параметризованные алгоритмы) —— Могут исполняться в любых конфигурациях любых инфобаз (без их модификации)

• При помощи внешней обработки Сервисный процессор. По COM \ DCOM \ OLEApplication эта обработка запускается в целевой базе и выполняет там этот сервис с входными параметрами – передается целый куст всех связанных сервисов. Если мы подали один алгоритм, а в нем есть ссылки на другие, значит, этот движок все это из центральной базы получает и все это оркеструет и запускает в целевой базе.

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

• Выполнение сервисов осуществляется строго в изолированном контексте. Чтобы никаких пересечений имен не возникало.

Преимущества парадигмы сервис-ориентированного программирования

• Прозрачность. Реляционные связи

—— Дерево подчиненности сервисов (параметризованных алгоритмов)

• Какие сервисы использует данный сервис (рекурсивно) • Какие сервисы используют данный сервис (тоже рекурсивно)

• Полноценный контроль ссылочной целостности

—— Нет необходимости использовать предопределенные элементы, НайтиПоКоду() и подобные, то есть – все ссылки добавили, в базе их сохранили, код на них ссылается, код их выполняет.

• Быстрый глобальный отбор \ поиск

—— По именам \ По скриптам \ По подсистемам. Например, нам нужно найти, как используется метод «УдалитьРегистрациюИзменений». Набрали в справочнике – сразу список 25 функций, где этот метод используется. Посмотрели код, подобрали, скопировали, сделали свой.

• Авторство \ История изменений \ Версионирование каждого объекта разработки (до уровня каждой процедуры \ функции, то есть сервиса по-нашему) • Стандартные реквизиты объектов разработки

—— Статус \ Пиктограмма \ Метаобъект \ Комментарий \ Подсистема \ Порядок \ Участники \Даты и другие

• Автодокументирование (генерация документации по любым сервисным объектам).

• Классификация и структуризация сервисов, так же как и других системных объектов может производиться с использованием иерархии подсистем и по настраиваемым критериям • Трассировки, замеры производительности, оптимизация

• Инструменты по быстрой и удобной разработке сервисов сами являются сервисами и могут

– 62 –

Михаил Харитонов

Практика централизации управления информационными базами и интеграционными процессами

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

• Диалоги-мастера по вставке вызовов одних сервисов из других сервисов • Генераторы шаблонов кода

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

Использование в сервисе других сервисов

• Синтаксический контроль программного кода • Синтаксическая подсказка при написании программного кода • Подключение синтакс-помощника по встроенному языку • Проверки соблюдения стандартов разработки —— Он-лайн (Перед записью сервисного объекта)

—— Офф-лайн (Автоматизированные пакетные проверки)

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

Структура сервиса

Классификация сервисных объектов Вот та самая простыня сервисных объектов, о которой я вам говорил:

Есть обязательные сервисные объекты – например, объекты метаданных всех систем (мы, как и все остальные, храним их централизованно).

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

– 63 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 по платформе – еще тогда бета-версия была. Несколько тысяч параметризованных Unit-тестов – каждый отдел тестировал объекты своей подсистемы. Здесь уже алгоритмы появились с параметрами.

• 2004 год – Сеть из15 магазинов фирмы «Реалист». Первая версия УТ++.Мы использовали наши наработки в боевых условиях проекта.

На закладке «Реквизиты» указан ответственный для каждой функции, документатор, разработчик.

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

Хроника становления сервис-ориентированной парадигмы программирования

—— Основная логика Прикладная и Интеграционная вынесена в параметризованный справочник Алгоритмы (пример, алгоритм РасчетЦены – сложный алгоритм с большим количеством ветвлений – наценка зависит от вида одежды, бренда, ткани, размерной сетки и так далее). Научили писать простой код 1С продуктового менеджера – он добавляет новый бренд, пишет, если бренд такой-то, то скидка 10. То есть, по сравнению с огромными сложными параметрическими настройками, которые постоянно в УТ меняются (там типы цен появились, здесь – расчетные – этот тип на этом…), мы сделали все проще – длинный, но прозрачный код, который человек едва знакомый с программированием поймет. Даже циклов нет. Главное – писать Если…ИначеЕсли – все очень просто получается.

• Репликация программного кода из центра по 15 периферийным базам

—— Событийная модель подписок на Алгоритмы (для объектов и форм)

• Централизованное управление регистрацией изменений (ПередЗаписью объектов)

• 2005 год – первая версия «БСП» от 2is. Текстильный холдинг «Арбен» ГК «Эликс»

• 2001 год – Конвертация данных, ред. 1 (версия 7.7) —— Справочник «Скрипты». Генератор программного кода. Интерфейсная обработка вызывающая другую, использующую директиву #ЗагрузитьИзФайла – полностью генерируемую. Пока – никакой параметризации.

• 2003 год – Первые версии параметризованных алгоритмов

—— КД ред. 2 – Инкапсуляция в xml-правилах обмена внешних обработок, Алгоритмов и Запросов, которые передаются в любую базу и там начинают выполняться.

—— Типовые операции «1С:Бухгалтерии 8» (там предусмотрены встроенные алгоритмы Проведения и ПриИзмененииПараметра – уже с параметрами)

—— Конфигурация тестирования платформы (несколько тысяч параметризованных Unit-тестов). Отдел разработки 1С дружно писал тесты

– 64 –

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

• 2007 год – Консолидация «Пятерочки» и «Перекрестка» (X5RetailGroup) —— МСФО. Мастер-данные. Интеграция БП++ на SOA архитектуре. В сильно доработанную версию «1С:Бухгалтерия 8» добавили ядро сервисных объектов (алгоритмы, запросы, схемы…)

—— Сеть Цвет Диванов (70 салонов) – УПП + Ядро 2is

• 2008 год – Проект «Автомир». На должность системного архитектора принят Старых Сергей. Началась новая веха.

—— Ядро почти полностью переписано

—— Реализована Объектно-ориентированная сервисная модель

• Наследование параметров \ Инкапсуляция (изоляция контекстов всех алгоритмов). Пример наследования: Объект базы данных

Михаил Харитонов

Практика централизации управления информационными базами и интеграционными процессами

–>Ссылочный объект (->СправочникСсылка) – свою какую-то классификацию добавляем…- наследуются параметры, методы и другие свойства.

—— Отладка сервисов в конфигураторе (генерация внешних обработок для каждого алгоритма-сервиса) —— Переименование справочника параметризованных Алгоритмов в Сервисы • 2010 год – Реализована первая версия мобильного сервисного процессора, который уже можно запускать в произвольных конфигурациях для выполнения сервисов.

—— Централизованное управление выполнением сервисов в разных базах разных конфигураций

—— В ГК «Автомир» внедрена схема масштабируемых обменов – Шина интеграции • Раздельные и параллельные доставка и обработка данных

• 2011 год – Проект удаленных вызовов мобильного сервисного процессора через Веб-сервисы

Видите, как он может выглядеть? На самом деле вы видите прототип и вполне рабочий, который пишется на специальной разновидности HTML. При исполнении, такой xmsl-код транслируется в язык 1С.

На рисунке, в первой строчке, мы определили запрос (вставляется гиперссылка на элемент справочника Запросы – соответствующий запрос), по этой гиперссылке щелкаем,запрос открывается красиво, в консоли запросов со всеми необходимыми инструментами для отладки этого запроса… Объявили параметры – во второй строке, параметру присвоили ссылку на объект базы данных. В третьей строке – вызвали сервис, передали в него запрос, вернулась ТЗ (таблица значений). Можем выполнять код по схеме,где к каждому элементу схемы привязан сервис.

Сквозные бизнес-процессы в гетерогенной среде

И последний слайд «будущего» – это вообще у нас готовый прототип, и уже опробованный (работающий) – сквозные бизнес-процессы в гетерогенной среде.

• 2012 год – Система централизации переписана с нуля на управляемом приложении —— Первая версия продукта «2is:Интеграция»

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

Рисуется графическая схема в справочнике графических схем. Каждый элемент этой схемы привязывается к выполнению сервиса с настройками в определенной базе. Нарисовали – появился новый договор в системе «Документооборот». Согласован/нет? Ждем. Система каждый час проверяет, его долбит в системе, ждет. Согласовался? О! – Передала его в другую систему – в Бухгалтерию.

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

– 65 –

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования Евгений Шумилов Руководитель и участник проектов по разработке тиражного программного обеспечения

От ведущего: Сейчас мы поговорим об одном из этапов разработки – о поиске багов. Почему тестирование сначала? На мой взгляд, это мое личное мнение, с утра тестирование воспринимается лучше. Считается, что на тестирование тратится очень много времени, поэтому его делать лучше не нужно. Потому что надо же разрабатывать, надо срочно писать код, а тестировать не нужно. Поэтому те самые баги, о которых Евгений сегодня будет говорить, – они чаще всего у всех живы. Евгений, а как Вы думаете, какой тезис надо знать людям для того, чтобы они все-таки тестировали свои программные продукты? Что-то вроде: «Если вы будете тестировать, то…» От докладчика: «Будет счастье».

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

работка инструментария для автоматизации этого процесса.

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

Почему именно наша компания?

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

Наша компания и ее миссия

Меня зовут Шумилов Евгений. Я являюсь директором дочерней компании «1С» и наша цель – разрабатывать инструменты для программистов, тестировщиков и администраторов, работающих с платформой 1С.

Зачем говорить про тестирование и зачем оно необходимо? Все представители сообщества Инфостарт связаны или с IT-сферой, или с бизнесом.

• Для бизнеса принципиально важно быстро внедрять.

• Основной вопрос, которым мы занимаемся, – это обновление измененных конфигураций и раз-

– 66 –

• Для большинства сфер деятельности важна и критична стабильность работы информационных систем.

Евгений Шумилов

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

• Соответственно, повышение качества может привести к конкурентным преимуществам.

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

Условные обозначения Далее в презентации будут использоваться следующие условные обозначения: • Программы • Ошибки

• Тестировщики. Так их принято называть во всем мире, это придумали не мы J

Что такое тестирование? Какими методами можно добиваться качества программных продуктов? Про некоторые из этих методов рассказывал Артур Аюханов на конференции InfostartEvent 2012. Повторять то, что рассказывал Артур, я не буду. Но, тем не менее, перечислю три основных способа повышения качества программных продуктов:

Для термина «тестирование» есть разные определения, но, наверное, самое правильное:

Тестирование – это процесс обнаружения ошибок.

• Первое и, наверное, самое главное, – правильное проектирование программных продуктов.

• Далее – качественное тестирование всего созданного или доработанного функционала.

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

Ручное тестирование В чем проблема ручного тестирования? Простой пример: протестировать УПП вручную практически невозможно.

• Это очень длительный процесс.

– 67 –

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

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Это очень трудоемкий процесс. Тестировать вручную можно, но тестировать регулярно вручную большой объем функционала занимает громадное количество времени. Часть функций не тестируется, а так как большинство объектов взаимосвязано, после неполного тестирования могут остаться ошибки.

Время внесения ошибок в программу По времени внесения ошибок в программу можно выделить следующие основные классы:

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

Что такое «ошибка» Это сбой программы, который приводит к неправильной работе, к прерыванию работы программы или к получению неправильных, некорректных данных.

• Методологические, логические, ошибки проектирования.

• Следующий класс ошибок, самый простой – это синтаксические ошибки, ошибки компиляции, ошибки нарушения стандартов разработки.

Есть большое количество различных видов ошибок.

• И самый неприятный для пользователей класс ошибок – это ошибки, которые возникают вовремя выполнения программы.

Методы классификации ошибок. Чтобы эффективно находить ошибки, необходимо их изучать и классифицировать. К основным способам классификации можно отнести: • когда ошибка была внесена в программу

• как она обнаруживается

Устойчивость и скрытность ошибок По устойчивости ошибки тоже можно классифицировать:

• как она себя ведет

• в какой среде обитает.

– 68 –

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

Евгений Шумилов

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

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

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

Виды тестирования для обнаружения ошибок Какие есть виды тестирования для обнаружения различных классов ошибок?

• Unit-тестирование

• Функциональное тестирование • Регрессионное тестирование • Нагрузочное тестирование • …

Многие из этих видов тестирования можно автоматизировать различными методами.

Среда обитания ошибок Возникновение или не возникновение ошибки может зависеть от различных факторов:

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

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

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

Методы тестирования

Продолжим классификацию методов тестирования. Есть два основных варианта тестирования:

– 69 –

• Ручное тестирование.

• Автоматическое тестирование.

INFOSTART JOURNAL №2 НОЯБРЬ 2013

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

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

• Есть продукты для тестирования, которые требуют наличия специалиста —— В самом простом случае – это оператор низкой квалификации

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

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

Как тестируют на 1С Сейчас в мире 1С самый распространенный способ тестирования – это тестирование с помощью пользователей. На самом деле, это самый эффективный способ тестирования. Чем больше пользователей начинают использовать «сырую» программу – тем быстрее будут найдены все ошибки. При этом качество конфигураций 1С очень принципиально. Иногда некоторые ошибки приводят к проблемам, и часто – к очень серьезным проблемам.

Тестировать с помощью пользователей можно (и все так и делают), но это неправильно. Сколько стоит ошибка, которая приводит к тому, что 10 пользователей не могут работать в течение одного часа? А если пользователей 100?

– 70 –

На каких этапах жизни программы можно применять тестирование?

• Проектирование.

• Разработка.

• Внедрение.

• Обновление. Все программные продукты обновляются в той или иной степени – соответственно можно применять тестирование после обновления • Поддержка. На этапе поддержки тоже могут быть какие-то модификации, изменения контекста работы программы, смена платформы 1С, смена

Евгений Шумилов

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

операционной системы и так далее. На этом этапе тоже можно применять тестирование.

• Доработки. Любое изменение программы требует тестирования. Тестировать необходимо на всех этапах.

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

• Первый программный продукт – это «Автоматизированная проверка конфигураций». Он позволяет находить: —— ошибки usability,

—— ошибки нарушения стандартов,

—— наличие различных ошибок в коде методами статического анализа.

• Этот инструмент просто необходим для разработчиков тиражных решений. Если конфигурация не проходит проверку «Автоматизированной проверкой конфигураций», это очень плохо. По стандартам разработки фирмы «1С» все конфигурации должны проходить такую проверку • Программный продукт – «Корпоративный инструментальный пакет» (КИП). В нем есть подсистема «Центр управления производительностью», которая позволяет производить нагрузочное тестирование. Его основная задача – поиск и устранение узких мест при работе с SQL сервером.

Инструменты тестирования Ручное тестирование – это хорошо.

Тестирование пользователями – это тоже неплохо.

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

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

Далее – переходим к инструментам автоматизации процесса тестирования. Профессиональных инструментов для тестирования на платформе 1С довольно много. Но многие про них ничего не знают.

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

• И последний программный продукт «1С:Автоматическое тестирование конфигураций»

Все эти продукты доступны для приобретения в фирме «1С» и в ее партнерской сети.

– 71 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Инструменты тестирования производства фирмы «1С-ИжТиСи»

Инструменты тестирования от других производителей

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

• Первый программный продукт, который мы выпустили в помощь тестировщикам – это «Управление работой приложений в операционной системе с использованием имитации работы пользователей». Фактически данный продукт представляет собой сценарное тестирование на уровне операционной системы. Он позволяет автоматизировать тестирование любой программы на уровне операционной системы. Этот продукт может тестировать как конфигурации 1С, так и любые другие приложения, которые работают на операционной системе Windows.

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

• Есть программный продукт «Нагрузочное тестирование» производства фирмы «Рарус».

• На Инфостарте есть ряд обработок, которые позволяют автоматизировать какие-то процессы тестирования.

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

Далее немного более подробно по каждому продукту.

Автоматизированная проверка конфигураций

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

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

• Ошибки проектирования • Синтаксические ошибки

• Ошибки нарушения стандартов разработки, публикуемые фирмой 1С

—— возможность за счет «горячей замены кода» исправлять различные классы ошибок без перезапуска информационной базы

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

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

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

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

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

– 72 –

Продукт распространяется бесплатно фирмой «1С».

Евгений Шумилов

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

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

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

• после этого контролируют работу,

• а после (при модификации программных продуктов) поддерживают и модифицируют тесты-сценарии.

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

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

Основное назначение – нагрузочное тестирование. Данный программный продукт довольно сложный.

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

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

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

Автоматизированное обновление измененных конфигураций, версия ПРОФ Следующий программный продукт в основном предназначен для тестирования после обновлений сложных измененных конфигураций. Это «1С:Автоматизированное обновление измененных конфигураций. ПРОФ». Если быть более точным, подсистема тестирования, включенная в данный инструмент. Его работа полностью автономна, тестирование полностью автоматическое.

– 73 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Не требует знания методологии работы тестируемой конфигурации. Не требует знания, как работает конфигурация, какие в ней есть функции, объекты и их взаимосвязи.

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

Преимущества автоматического тестирования Минимальное участие человека во время тестирования – это принципиально. Для статистики, мы проводим 600 тестирований конфигураций. У нас этим занимаются два человека. При этом мы тестируем конфигурации принципиально разные. У нас более 200 различных конфигураций, которые мы тестируем. И те два человека, которые занимаются тестированием этих конфигураций, в принципе, не могут знать все эти конфигурации, как они работают, их нюансы и т.д. При этом часто мы получаем интересные отзывы от заказчиков тестирования. Для примера приведу один случай. Сложный проект, итерации делаются раз в неделю. Заказчиком осуществляется ручное тестирование силами двух методистов, которые знают все о внедряемой конфигурации. Когда мы выслали им список из 40 ошибок свежего релиза, они спросили: «Как Вы это сделали?»

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

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

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

Основной принцип работы данных программных продуктов: • автоматический анализ конфигураций

• автоматическая генерация сценариев тестирования

– 74 –

• последующее автоматическое исполнение сгенерированных сценариев

Евгений Шумилов

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

• автоматическое протоколирование всех найденных ошибок без остановки тестирования.

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

• любые конфигурации в режиме «Предприятие», в толстом, тонком, веб-клиентах

• можно тестировать и выполнять различные операции в режиме «Конфигуратора»

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

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

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

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

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

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

– 75 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 сказаться на деятельности организации. Ведь остановка большой компании на 10 минут или на час может обходиться для бизнеса очень дорого.

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

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

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

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

• что правильно устанавливается защита,

• что правильно устанавливаются драйвера защиты, • что правильно устанавливается обновление,

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

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

Юнит-тестирование Unit-тестирование – это очень специфическая вещь. Она меняет идеологию разработки программных продуктов.

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

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

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

– 76 –

Евгений Шумилов

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

Рарус. Нагрузочное тестирование

Что дает автоматизация?

Вероятно, это лучшее решение на рынке по тестированию производительности работы с СУБД. Это разработка компании «1С-Рарус» (gilev.ru). Она позволяет мониторить и находить узкие места в производительности информационных систем и оборудовании. Также он выдает базовые рекомендации по тому, как решить те или иные проблемы.

• Первое – это качество. Качество программных продуктов – это принципиально важный момент. Ведь это удовлетворение пользователей и «счастье во всем мире».

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

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

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

Выводы: • Для повышения качества и надежности программного обеспечения нужно применять различные методики

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

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

– 77 –

Альтернативные системы контроля версий и практика применения с 1С Евгений Сосна Профессиональный разработчик 1С, один из разработчиков скриптов для проекта Снегопат (8.х)

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

От докладчика: Я собираюсь рассказать о том, каким образом мы с вами можем использовать для разработки в 1С альтернативное программное обеспечение контроля версий, которое существует сейчас в мире. Если выбирать емкое слово, которое должно отразить доклад, то это, наверное, слово «ветки» – ветвления.

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

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

—— Альтернатива хранилищу, позволяющая организовывать «ветвления». Линейная история: простота – не значит удобство.

—— Обзор кода – свежий взгляд на «бистро-код». Что же изменилось на последних этапах разработки в модулях?

—— Авторство кода.

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

История развития систем контроля версий

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

Историю развития систем контроля версий можно разбить на несколько этапов:

1. Файловые (локальные) копии

Краткий план доклада

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

• Сначала я планирую рассказать про историю развития систем контроля версий. На каком этапе сейчас находимся мы с вами.

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

– 78 –

Евгений Сосна

Альтернативные системы контроля версий и практика применения с 1С

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

2. Локальные системы контроля версий

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

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

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

Открытыми системами этого типа являются CVS и SVN. До вчерашнего дня я думал, что CVS (ConcurrentVersionsSystem) уже можно выкинуть на свалку истории, но, оказывается, есть в нем некоторые моменты, которые все-таки до сих пор применимы и в наших сегодняшних жизненных реалиях.

Subversion (SVN– сокращение от названия клиента для командной строки, входящей в состав пакета) – это эволюционное развитие CVS. По сравнению со своим прототипом что-то нашло, а что-то потеряло.

И, в принципе, эти локальные задачи контроля версий на тот момент решало такое программное обеспечение, как RCS (RevisionControlSystem). Я его упоминаю ради исторической справедливости. Потому что использовать подобную систему контроля версий имеет смысл только тогда, когда для разработки используется локальная база. Когда у вас и во всем мире начинается командная разработка, эта система контроля версий уже не подходит.

Хранилище 1С тоже является централизованной системой хранения версий. В принципе, в хранилище у нас есть и сервер, и права доступа, и две чашки кофе вы можете успеть выпить, пока захватите рекурсивно весь корень конфигурации, да? А если по http-доступу еще или по tcp – ваше счастье… Придется долго ждать. Работа централизованных систем версий проста. Для каждого программиста-новичка понятна.

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

В некоторой степени системы на основе 1С:Документооборот или БСП с подсистемой версионирования файлов также являются локальными системами контроля версий.

– 79 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 дущему выступлению). Разработчики типовых конфигураций не покрывают код тестами. То есть, дописал свое, запустил полное тестирование, проверил, как работает – такого нет. Будет ли? Время покажет.

1. Получил из хранилища 2. Захватил

3. Отредактировал

4. Поместил обратно.

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

Но у централизованных систем есть и некоторые недостатки: 1. Первый недостаток – это, конечно, то, что сервер фактически является «единой точкой отказа». В связи с этим совет: делайте backup хранилища. На самом деле, хотя бы базы данных. Но хранилища тоже, пожалуйста, делайте. Потому что если с сервером что-то случится – восстановиться можно будет только из backup-а.

2. Следующая особенность – пессимистическая блокировка. Некоторые считают, что, когда в централизованной системе разработчик захватывает объект, он,таким образом, всем объявляет свое намерение, что собирается в этом объекте что-то изменить. К тому же, многие руководители думают, что они, таким образом, контролируют этого разработчика. То есть, раз разработчик захватил какой-то там документ – значит, мы знаем, что он над ним работает, и он его к какому-то периоду времени сделает. По факту, если это уже опытный специалист, и вы ему доверяете, то он,конечно, всегда обоснует, почему он месяц назад объект захватил и до сих пор не поместил его в хранилище. Но, все равно – эта пессимистическая блокировка накладывает на нас ограничение, которого можно было бы избежать. В дальнейшем в распределенных системах обошли этот путь. Также, если у вас идет глобальный рефакторинг, или идет какое-то исправление модуля и срочно необходимо исправить ошибку – тоже может возникнуть проблема. В худшем случае – база стоит, ничего не работает. В лучшем – возникает дилемма, 50% кода уже исправлена, то ли помещать в хранилище неоттестированный код, то ли сохранять его куда-то в файл. И у нас опять появляется в файловой системе «Копия конфигурации такой-то» и мы забыли/не забыли ее вернуть обратно в конфигурацию.

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

4. Распределенные системы контроля версий Следующим этапом развития систем контроля версий стали, конечно же, распределенные системы. Основная идея этих распределенных систем контроля ревизий – это ветвление.

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

– 80 –

Евгений Сосна

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

работчиков трехстороннее сравнение в конфигураторе скрыто.

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

• Ветвление, естественно, является палкой о двух концах. Оно, как линия жизни вашего проекта,может уйти куда-то в сторону, а может держаться генеральной линии. Это надо прочувствовать на себе. И основной принцип – ветвиться часто, но в меру.

Ключевые особенности

Итак – что отличает распределенные системы контроля версий от всех остальных?

Режимы работы распределенных систем

Распределенные системы поддерживают различные режимы работы.

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

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

– 81 –

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

• Можно по старинке – с центральным сервером. Причем вы можете копировать не полностью весь репозиторий на него, а только нужные вам для хранения истории файлы. Допустим, выгрузка хранилища 8.3 занимает 1.5 Гб. Разработчику первый раз выгрузить содержимое репозитория по каналу интернета очень тяжело. В то же время, можно выкачать только последние изменения, с которыми он работает. Так, поддерживается тот же принцип централизованной системы, как и в хранилище.

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

• И наконец, самый предпочтительный и самый удобный способ – с центральным сервером, с локальными фиксациями и ветками. Однако настройка будет наиболее трудоемкой.

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Какие есть системы?

—— Простейший баг-трекинг —— Встроенный web-сервер

Альтернативы достаточно разнообразны:

• Управляется с web-браузера • Единственный недостаток – нет GUI-интерфейса, к которому все привыкли. То есть,мышкой покликать, чтобы сделать коммит/добавить файл – не получится. Посмотреть изменения через web-интерфейс можно. Но все остальное стандартно, только через консоль

Я специально выделил Mercurial – потому что, к сожалению, если брать практику разработки хранения версий именно для 1С – эта распределенная система не подходит. У нее есть проблемы с кодировками в наименованиях файлов и, когда перед вами встанет вопрос об осуществлении обмена с другим сервером (например, один сервер будет базироваться на ОС Windows 7, а другой – на WindowsXP), вы не сможете синхронизировать данные из-за различного представления кодировок имен файлов для различных ОС. То есть, к сожалению, его нельзя пока использовать. Хотя это моя любимая система, т.к. она более логичная и с ветками работает наиболее понятно. Особенно для новичка, делающего попытки разобраться в принципах работы.

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

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

Здесь приведен простой скриншот web-интерфейса fossil с реальной работы. Внизу видно, как какая-то

SCM fossil

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

ветка разработчика слилась в основной ствол дерева.

Практика применения

Ее особенности:

• Проста • Удобна

• Весь пакет инсталляции содержит один файл exe, который содержит в себе —— Систему версионного контроля

—— Систему документирования на основе wiki

– 82 –

Евгений Сосна

Альтернативные системы контроля версий и практика применения с 1С

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

• Система управления задачами – Redmine. Я использую ее совместно с удобным плагином для обзора кода CodeReview • Сервером для Git у меня служит такая программка, написанная на Java, как Scm-Manager,– контроль репозиториев. Удобно ставится, настраивается через простейший web-интерфейс – запустили, и все работает.

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

В результате для задачи в системе Редмайн в поле «Связанные редакции» вы получите такую картинку –

• TortoiseGit – клиент для Git под Windows на основе «черепахи». Кто работал с Subversion – тот знает, что есть такой TortoiseSVN, TortoiseGIT и пр.

• И главный виновник торжества – 1С:Предприятие 8.3. Это то, что нам позволяет полностью выгрузить конфигурацию в файловую систему.

Связь коммита с задачей Рассмотрим простейшие понятия. Может, это даже

можно перейти, посмотреть, какой код изменялся. Это очень удобно.

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

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

Ветвление Самих способов ветвления три. Остальное – их комбинации.

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

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

Эта тема очень большая и актуальная.

– 83 –

• Ветвление по функционалу.

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

—— добавить новый объект —— отпустить корень

—— Работать над объектом

—— Если он кому-то понадобится – отпустить

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Потом опять захватить и т. д.

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

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

• Следующий способ ветвления – ветвление по пользователям. Тоже применяется. Например, у вас есть удаленный разработчик, или какой-то новый молодой специалист. И у вас стоит компромисс – или дать доступ на запись в хранилище или… По мне, так это – «пусти козла в огород»… Если не проконтролировать, что он там изменял, завтра с базой будет совсем плохо. Одно дело, если этот «специалист» рядом сидит, и его проконтролировать и сделать ему какие-то замечания не составляет труда. А если это удаленный разработчик и он уехал куда-то в Таиланд – то… хранилище не поможет вам этого разработчика проконтролировать. Только если дать ему конфигурацию хранилища на чтение, а потом вам или ему мучиться с объединением. Никто не захочет дальше работать с вами. А возможность использовать трехстороннее сравнение позволяет определить именно те объекты, которые были дважды изменены, и быстро, с помощью различных инструментов типа kdiff3, их объединить. Это дорогого стоит.

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

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

Обзор кода

На прошлой конференции Артур Аюханов говорил, что одним из методов повышения качества кода является обзор кода. Если быть честным – в хранилище обзор кода мы сделать не можем. То есть, согласно модели работы, когда у вас база подключена к хранилищу, вы не знаете, какая версия у вас в принципе сейчас есть в хранилище. Безусловно, действием «Обновить конфигурацию из хранилища» вы можете получить к себе на компьютер последние изменения. Но, по факту, часто разработчики захватывают только те объекты, с которыми им нужно работать, и в результате может получиться какая-то сборная солянка.

Конечно, это решается административным путем. То есть, пришел утром на работу, сделай обновление конфигурации из хранилища. Посмотрел, что у тебя в хранилище 10 объектов измененных, смотришь «А кто их изменял?». Если там два программиста – еще можешь спросить/узнать, что же там изменяли. А если больше двух? Здесь начинается проблема коммуникаций, и понять – кто же что изменял в хранилище, довольно-таки трудно. Соответственно – обзор кода нам позволяет заставить себя исправить наш «бистро-код». То есть, вы быстро его сделали, забыли, потом посмотрели. В Редмайне это позволяет вам, если что-то не нравится,встать на ту строчку кода, которая вам не нравится, нажать «Создать задачу»и назначить ответственным за эту задачу того, кто поместил этот код в хранилище. Эта задача висит над ним, как «дамоклов меч». Она, конечно, может висеть долго-долго, а может сразу исправляться.

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

– 84 –

Евгений Сосна

Альтернативные системы контроля версий и практика применения с 1С

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

Авторство кода

Самая интересная картинка – «Авторство кода».

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

В хранилище я пока не знаю, как получить «Кто же писал эти строки?»

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

А тут, с помощью любого редактора, поддерживающего вывод авторства строк (того же GIT), вы можете встать на определенную строчку кода, и он вам покажет ту версию, с которой это было изменено. А потом еще дополнительно покажет все версии этого файла, которые были в системе контроля версий. Думаю, многие с этим встречались, и кто-то может сказать, что все равно неизвестно, кто виноват (один программист одно условие добавил, а кто-то выше добавил еще какое-то условие – это он виноват).

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

• Во-первых, ваша древовидная конфигурация превращается в файловой системе в линейный список. То есть, например, наиболее распространенная конфигурация УТ10.3, в разобранном виде превращается в 9451файл в одной папочке. Причем, ориентироваться по таким файлам просто невозможно (Документ.Реализация.МодульОбъекта.txt). С учетом того, что по алфавиту там сначала идут роли, найти в этом списке нужный объект очень затруднительно.

—— Соответственно, для этого я использую такой метод – я выгружаю файл конфигурации в отдельную папку, а потом из этой папки копирую файлы в хранилище GIT с учетом структуры каталогов. То есть эта структура повторяет то же дерево, которое у нас есть в конфигурации. Для этого у меня есть специальная обработка, которая по точке, методом «МассивРазложитьВСтроку» разносит файлы по каталогам. Это позволяет наглядно посмотреть. Опять-таки, нам в скором времени обещают в 8.3 ускорение работы с хранилищем, но, в принципе, при такой выгрузке с помощью GIT все равно то же самое получается. Вы получаете ту же самую информацию – только быстро, удобно… даже при ее линейном формате. Так же, как это в хранилище и есть.

• Еще немаловажный факт – обычные формы выгружаются во внутреннем формате. То есть, файл форм «закодирован» во внутренний формат 1С. Почему так сделано, мне, если честно, непонятно, так как в 8.2, допустим, у нас есть возможность получить модуль формы. Еще раз уточню: это касается только «толстых» форм. Я понимаю, что управляемые формы «побеждают весь мир», но УПП 2.0 еще не вышло, а у нас еще есть УПП1.3, которое еще на «толстых» формах – живет и здравствует.

– 85 –

—— для этого есть обходные пути – есть такая

INFOSTART JOURNAL №2 НОЯБРЬ 2013 чудная программа V8Unpack, которая распаковывает эти формы на внутреннее представление формы и на модуль формы. Соответственно, эта проблема просто обходится.

• Огромный объем выгрузки ролей в файлы.

—— для меня стало неожиданностью, когда я увидел, что, оказывается, роли выгружаются полностью, то есть, есть возможность указать для роли «Право по умолчанию» на объекты. Но, все равно, роли выгружаются полностью. И, соответственно, есть проблема в хранилище. У вас, допустим, роль не захвачена, и в то же время вы добавили какой-то реквизит в документ. Вроде как только изменения документа идут, да? Если вы сделаете выгрузку конфигурации в XML, то у вас окажется, что у всех ролей есть изменения – добавлено новое право на новый реквизит (явное разрешение на чтение этого реквизита). Подчеркну, в выгрузке XML – изменение во всех ролях!!

Таким образом, я смог сконвертировать хранилище 1С в альтернативную систему контроля версий. Конечно же – больше всего времени заняла выгрузка в 8.3 в файлы. И еще создание конфигурации из версии хранилища.

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

Выводы

Соответственно, краткие выводы:

1. Как альтернатива, вы можете использовать сейчас и GIT, и SVN, и BZR, и fossil – это все поддерживаемые системы. Если говорить про какую-то интеграцию с системой баг-трекинга, то здесь побеждает SVN и GIT. Если вы еще захотите ветвления – то, конечно же, без альтернативы GIT. То есть, вроде как у вас есть альтернатива – но, тем не менее, альтернативы нет.

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

• И, конечно же, нет выборочной выгрузки/загрузки. Я не говорю даже о скорости загрузки/ выгрузки. Но, хотя бы выборочно выгружать, чтобы как раньше – можно было частично выбирать – выгрузить только документы или определенные документы. У нас бы стало проще с работой, не так долго нам пришлось бы выгружать/загружать эти данные, мы могли бы быстрее получать готовый результат.

2. Синхронизация хранилища 1С с git работает.

3. Ветвление, в принципе,работает.

4. Единственный минус – просто так взять и воспользоваться в этом плане 8.3, к сожалению, нет возможности, то есть, без доработок не обойтись.

Порядок выгрузки

Если судить по опыту, я взял хранилище на 8.2 (там история разработки более 500 ревизий).

• В этом хранилище я брал каждую версию и выгружал ее в cf-файл, • Потом загружал в 8.3,

• И, наконец, выгружал в файловую структуру.

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

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

– 86 –

Новые возможности платформы «1С:Предприятие 8.3» Андрей Аристархов 1С, Представитель отделения разработки фирмы “1С”. Руководитель направления «Инновации и интегрированные решения»

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

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

Спасибо вам за то, что вы делаете, спасибо за то, как вы автоматизируете. Цифры IDC говорят сами за себя.

А мы, в свою очередь, стараемся сделать все, чтобы вы могли это делать более эффективно.

Развитие и продвижение программных продуктов фирмы 1С. Статистика Вначале посмотрите, как мы все вместе хорошо работаем.

На этом слайде представлена информация с сайта 1С. Она публично доступна. Есть монитор продаж/внедрений УПП. Небольшие цифры, можете посмотреть. Это данные на конец апреля.

В 2011 году 1С был единственным вендором в сегменте ERP систем, который увеличивал свою долю рынка.

Если в 2010 его доля была 26%, то в 2011 – она уже 31,6%.

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

73 внедрения ERP-систем за месяц – хороший результат.

– 87 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

КАМАЗ. Да, что там делают 7000 человек – на КАМАЗе? Не поверите – работают. Причем, работают очень эффективно. Да, естественно, это внедрение в группе компаний, но это – единая система, где увязано более 7000 человек.

Этапы развития платформы 1С:Предприятие

Развивая 8.2, мы постепенно двигались в сторону облачных направлений, добавляли какой-то новый функционал, например,multitenancy. Это были такие отдельные «пробы пера» – технологические новинки в области облачных технологий.

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

• Это сложные системы

А теперь – по развитию платформы.

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

• Linux – скажите, кто рад тому, что 1С полностью работает на Linux? Вот видите, как много радости мы вам принесли с новой версией!

• Кому интересна мобильная платформа? Еще больше – супер!

Сейчас параллельно поддерживаются и развиваются две ветки – текущий релиз ветки 8.2 – 8.2.18 (уже вышла), 8.3.3 – выходит.

В какой-то момент, естественно, развитие ветки 8.2 будет остановлено. Будет развиваться только ветка 8.3.

Новые возможности 8.3. Основные направления

– 88 –

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

Облачная платформа 1cFresh

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3»

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

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

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

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

Есть два продукта – технология разработки решений 1сFresh и технология публикации решений 1сFresh. Чем они отличаются?

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

Причем, элементы облачной архитектуры реализованы не только в рамках прикладных решений «Менеджер сервиса» или «Агент сервиса», они также затрагивают «Библиотеку стандартных подсистем» (для работы необходима внедренная подсистема «Работа в модели сервиса» из БСП). К тому же, некоторые механизмы заложены в платформу(тот же механизм multitenancy – заложен в платформе).

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

• Менеджер сервиса

– 89 –

• Агент сервиса

INFOSTART JOURNAL №2 НОЯБРЬ 2013 или иначе, уже используются, и можно совершенно спокойно интегрировать 1сFresh в уже существующее общее облачное пространство. Для этого соответствующие инструменты и интерфейсы есть.

• Демонстрационное приложение «Работа в модели сервиса»

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

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

Что было важно:

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

• Если посмотреть на методологию, код надо менять совсем немного. Есть несколько моментов, которые отражены в данной методологии, где необходимо менять код. Менять его надо просто с учетом того, чтобы приложение одновременно могло работать и в коробочном варианте (клиент-серверном) и в облачной модели. На самом деле, платформа достаточно уникальна. Вы представляете себе – desktop-приложение, клиент-серверное приложение, облачное приложение… И все это – один и тот же код.

• Возможность быстрой разработки и старта «с нуля» небольших облачных решений. Быстрота разработки на платформе вам хорошо известна. Теперь можно и облачные решения быстро разворачивать.

• Готовое решение для «облака» мобильных абонентов. Вообще – это два основных технологических тренда: облачное направление и мобильное направление. То есть, они так «двигают». Причем, они взаимосвязаны. Потому что – если у вас есть мобильное устройство, то вам нужно где-то хранить информацию. А где? У кого iPhone – хранит информацию в iCloud – в «облаках». То есть, «облака» и «мобильное» – тесно вместе связано.

Вот таким вот образом устроен наш сервис – 1cfresh. com

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

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

– 90 –

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3» • Переход из локальной версии в сервис и обратно

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

• Персональные резервные копии

• Обмен данными между приложениями абонента в сервисе

• Обмен данными между приложениями сервиса и локальными приложениями • Интеграция между приложениями и системой сдачи отчетности

• Доступ к методическим информационным ресурсам • Автоматический сбор статистики по работе сервиса • Другие возможности

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

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

Здесь представлен перечень технологических функций, которые реализованы в сервисе 1cfresh. com. Вы уже видели их – в виде квадратиков при показе инфраструктуры облачного решения.

• Взаимодействие партнеров и клиентов (актуально для провайдеров) • Мониторинг работоспособности компонент сервиса и оповещение администраторов

• Информирование о запланированных и незапланированных простоях

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

• Единая аутентификация (OpenID)

• Автоматическое обновление версий приложений • Автоматическое обновление нормативно-справочной информации

– 91 –

• Требуется внедренное БСП.

—— С подсистемой «Работа в модели сервиса». Там как раз реализован некоторый слой абстракции, который позволяет вам не думать о том, в какой модели работает приложение – в локальной модели или в модели сервиса.

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Описано в руководстве по технологии разработки 1cFresh

• Очень важно то, что качество решений, которые разворачиваются в «облаке», должно быть значительно выше. Потому что, если у вас работает 20 человек – это одна нагрузка. Но когда у вас работает 100 компаний, 100 подразделений по 20 человек –это уже совершенно другая нагрузка. Поэтому я говорю о том, что облачная инсталляция сравнима с большим корпоративным внедрением. То есть, решение должно быть

Для упрощения администрирования были произведены следующие улучшения:

—— Более производительным —— Менее ресурсоемким

—— Более надежным и корректным

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

Развитие кластера серверов 1С

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

Произошла значительная модернизация по направлениям: • Упрощение администрирования

• Повышение масштабируемости и надежности

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

– 92 –

• Реализована новая архитектура балансировки нагрузки кластера серверов

—— Администратор определяет состав компьютеров (рабочих серверов), на которых размещается кластер

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

—— «требования» к рабочим серверам могут быть заданы: • интерактивно, из консоли администрирования кластера, • или программно, из встроенного языка

• Развитие средств администрирования кластера серверов —— Сервер администрирования (RAS)

—— Утилита командной строки позволяет администрировать все. То есть,функции администрирования теперь стали доступны, в том числе и из кода 1С.

—— JAVAAPI. Появление JAVAAPI произошло по причине того, что платформа 1С стала полностью кроссплатформенной, то есть появилась поддержка Linux. Поэтому – должен был появиться некоторый универсальный интерфейс – он был реализован в виде JAVAAPI.

• В составе кластера реализованы два новых сервиса

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

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

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3»

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

Дополнительные настройки кластера

Возможности настройки кластера серверов 1С были расширены по следующим направлениям:

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

—— Автоматическое распределение рабочих процессов по серверам кластера

—— Автоматическое распределение сервисов и сеансов по серверам кластера

—— Автоматическое распределение соединений пользователей по серверам кластера —— Анализируется время реакции, количество соединений с рабочим процессов, количество ИБ на рабочем процессе

• Ручная настройка.

—— Настройка места выполнения сервисов и сеансов ИБ

—— Запрет выполнения сервиса на конкретном сервере —— Настройка количества ИБ и соединений на один рабочий процесс

—— «Тонкое» управление параметрами использования оперативной памяти – можно выставлять ограничения: сколько памяти может быть использовано за один вызов и вообще – сколько памяти может использовать конкретный рабочий процесс.

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

– 93 –

• Распределение нагрузки в кластере. Тоже можно задавать различные политики распределения нагрузки.

—— Приоритет по производительности

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

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

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

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

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Безопасный режим исполнения кода позволяет запретить внешнюю активность кода, не являющегося частью конфигурации

Особенности использования кластеров в качестве сервиса.

• Пользователи кластера относятся к разным организациям (абонентам) и используют изолированные друг от друга множества данных. Различные сценарии использования: —— Несколько абонентов в одной информационной базе с типовой конфигурацией

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

—— Отдельные информационные базы абонентов с индивидуальными конфигурациями

• Профили безопасности. Механизм, обеспечивающий изолированность базы абонента от внешних ресурсов

• Не требуется или требуется минимальная доработка конфигураций.

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

• Профили безопасности определяются в рамках кластера

• Позволяют администратору кластера контролировать разработчиков конфигураций и внешних отчетов/обработок

• Профили безопасности можно настраивать непосредственно в конфигурации информационной базы • Могут использоваться

—— При регистрации информационной базы —— В коде конфигурации

Внешняя активность конфигурации (регулируется профилями безопасности).

• Информационные базы располагаются в отдельных базах данных и их данные изолированы. Однако, конфигурации имеют доступ к внешним, по отношению к 1С:Предприятию, средствам: —— Файловая система сервера —— Объекты COM

—— Внешние компоненты 1С:Предприятия —— Внешние отчеты и обработки

—— Приложения операционной системы —— Ресурсы интернет

– 94 –

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3» информационной базы

• Профили безопасности позволяют управлять доступом из кода конфигурации к внешним по отношению к 1С:Предприятию ресурсам:

—— СУБД IBM DB2: увеличена параллельность при работе большого количества пользователей

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

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

—— СУБД Oracle Database: ускорена работа с итогами, ускорена работа при использовании сложных ограничений на уровне записей и полей, ускорено обновление конфигурации информационной базы

• Повышена масштабируемость и производительность кластера серверов

• Оптимизация работы со сложными запросами и большими объемами данных

Вы знаете, что интересно? Самое большое количество задач по оптимизации было сделано в рамках SQLServer. Наверное, это объясняется еще и тем, что мы занимались и вопросом поддержки новой версии SQL Server.

По поводу профилей безопасности – я еще хочу сказать… Кто знает, что такое «Заметки зазеркалья»? По профилям безопасности там есть отдельная статья, где вы можете про все это подробно посмотреть.

Производительность

Управляемые блокировки по реквизитам объектов Здесь представлен хороший пример того, что, с одной стороны, мы позволяем более эффективно управлять блокировками, а, с другой стороны, механизм «Управляемых блокировок по реквизитам объектов» надо использовать все-таки разумно, потому что, если вы задействуете данный механизм, у вас возрастает нагрузка на систему.

• Возможность блокировки объекта не только по ссылке, но и по произвольному набору реквизитов • Настройка реквизитов, участвующих в пространстве блокировки —— Поле «Ссылка» и общие реквизиты в режиме разделения «Независимо и совместно» включаются автоматически

Оптимизация • Оптимизирована работа с различными СУБД: —— Microsoft SQL Server: уменьшено количество блокировок при многопользовательской работе, ускорена работа с временными таблицами, ускорена запись и чтение данных, ускорена загрузка информационной базы из файла, ускорена реструктуризация информационной базы —— СУБД PostgreSQL: ускорено обновление итогов, реализована возможность размещать индексы и данные на разных физических носителях, ускорено обновление конфигурации

• Дополнительная нагрузка на систему

—— При записи объекта 2 блокировки – по старым и новым значениям

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

– 95 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Позволяет ускорить работу тяжелых запросов • Требует ручного запуска через ТиИ

• Желательно выполнять на регулярной основе

• Ускорено открытие управляемых форм • Работа в терминальном режиме.

—— Значительно ускорен запуски значительно снижена нагрузка при работе в терминальном режиме большого количества пользователей.

Регистры накопления и бухгалтерии • Установка минимального периода рассчитанных итогов —— Позволяет сократить объем хранимых данных —— Ускоряет пересчет итогов

—— Ускоряет работу неоптимальных запросов • Полный скан таблицы итогов

—— Ускоряет запись движений задним числом

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

Фоновое обновление конфигурации базы данных. Скажите, у кого обновление информационной базы занимает сутки? У кого – 12 часов? У кого 2 часа? А у остальных сколько? 10 минут?

Смотрите. Работает облако – некая корпоративная система, где подразделения существуют во всех часовых поясах России и еще где-нибудь за границей. Система должна работать 24/7. А как ее обновить? Сложно. Особенно, если объемы информации такие, как в «Тандере» – исчисляются в терабайтах. Эта задача реализовывалась на самом деле достаточно долго. Мы давно этой задачей занимались. В 8.3 мы ее сделали.

Часть решений по оптимизации включена в версию 8.2.18 • Оптимизирован файловый вариант работы —— Работа с сеансовыми данными

—— Запросы на чтение, так и на запись

—— Ускорены запросы с RLS (локально и в сети) —— Сложные отчеты при работе (по сети)

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

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

– 96 –

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

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3»

—— Предварительный перенос данных

—— Перенос изменений, сделанных за время копирования (может повторяться несколько раз) —— Окончательный перенос изменений

• В конечной фазе – монопольный режим

• Не все объекты переносятся в фоновом режиме

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

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

Запись журнала действий пользователя (журнал действий пользователя записывается в формате XML)

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

Автоматизированное тестирование.

• Доступен при запуске с ключом командной строки —— Новый ключ /UILOGRECORDER

• Может запускаться из конфигуратора • Новые кнопки заголовка

• Интерактивное управление с помощью кнопок —— Пользователь должен явно запустить запись в клиенте —— Можно остановить запись, сохранить результат или отказаться от записи

• Формирует результат в виде XML

• По окончании записи отображает результат пользователю • Результат может быть преобразован специальной обработкой в исполняемый код системы автоматизированного тестирования (будет выложена на ИТС)

Ну, наверное, это задача всем хорошо известная – хочу запустить, «потыкать», записать… А потом воспроизвести, чтобы это проверяло мои ошибки. Приблизительно этот механизм и был реализован.

• Механизм базовой функциональности для автоматизированного тестирования • Запись журнала действий пользователя

• Не требует модификации тестируемой конфигурации (приложения)

• Можно разрабатывать тесты для управляемого приложения (в том числе и для веб-клиента)

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

• Доступен при запуске клиента с новыми ключами командной строки.

– 97 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Какие новые термины появились в рамках тестирования?

• Тест(сценарий тестирования)– программа на языке 1С • Менеджер тестирования • Клиент тестирования

—— Управление приложением

—— Тестируются толстый, тонкий и веб-клиенты

• Менеджер и клиент могут быть подключены к разным информационным базам

Клиент тестирования • Доступен при запуске с параметром командной строки —— Новый параметр /TESTCLIENT

• Тонкий клиент или толстый клиент в режиме управляемого приложения

• Обеспечивает имитацию интерактивных действий • Взаимодействие через TCP/IP

—— Идентификация через имя/адрес компьютера клиента и уникальный номер порта

Менеджер тестирования: • Доступен при запуске с параметром командной строки —— Новый параметр /TESTMANAGER

• Обеспечивает выполнение теста, передачу команд клиенту тестирования, оценку результатов • Может управлять несколькими клиентами тестирования одновременно —— Не может управлять собой

• При взаимодействии с клиентом передаются только примитивные типы —— Без ссылок

Кто с Тест-центром сталкивался? Тут идеология тестирования приблизительно такая же. Есть центр управления тестированием (менеджер тестирования), есть клиенты, которыми он управляет. Со стороны менеджера идут команды. Клиент присылает обратно данные.

– 98 –

Веб-клиент, как клиент тестирования

• 3 субъекта – менеджер, веб-сервер, веб-клиент

—— Web-адрес информационной базы веб-клиента тестирования вызывается с дополнительными параметрами • TESTCLIENT и TESTCLIENTID =<Идентификатор>

—— Менеджер взаимодействует с клиентом через веб-сервер • Менеджер с сервером через TCP/IP • Сервер с клиентом через HTTP

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3» —— В работе нужно опираться на поддерживаемый набор действий

• Набор проверок ограничен

—— Проверка через получение представления данных —— Проверка результатов выполнения некоторых функций —— Проверка через поиск объектов тестирования

—— Для проверки данных, сформированных в ходе теста, нужно обращаться к базе тестируемого клиента

• Механизм будет развиваться

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

Веб-приложение тоже можно запустить в режиме клиента тестирования. То есть, для веб-клиента. Но здесь, естественно, необходимо взаимодействие через веб-сервер. Здесь менеджер тестирования с веб-сервером взаимодействует по TCP/IP, а клиент, стандартным образом, по HTTP. Объектная модель

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

Linux

—— ТестируемоеПриложение

—— ТестируемоеОкноКлиентскогоПриложения —— ТестируемаяФорма

—— ТестируемаяГруппаФормы —— ТестируемоеПолеФормы

—— ТестируемаяТаблицаФормы

—— ТестируемаяДекорацияФормы —— ТестируемаяКнопкаФормы

• Предоставляют некоторые свойства, описывающие состояние объектов, и методы для действий над объектами

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

Linux – уже год работает.

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

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

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

– 99 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Новый Файл (“/tmp/file.txt”) и Новый Файл (“\tmp\file.txt”) – ОК

—— При работе с внешними приложениями нужно использовать «родной» разделитель —— Новые методы глобального контекста • ПолучитьРазделительПути

• ПолучитьРазделительКлиента • ПолучитьРазделительСервера

Те, кто с Linux не сталкивался, таких особенностей может не знать. Для обхода этих особенностей были доставлены некоторые новые методы, позволяющие писать «кроссплатформенные» приложения. Клиентские приложения и средства администрирования для Linux • Клиентские приложения аналогично приложениям для ОС Windows —— Для конечных пользователей

—— Для разработчиков/администраторов

• Приложения не требуют переделки (возможны доработки в части системно-зависимых функций) • Поддерживается файловый и клиент-серверный варианты работы • Реализованы для архитектуры х84 и х86-64 (Intel)

• Администрирование (сервер, утилиты командной строки, Java-API).

Особенности файловой системы (файловые маски) • Работа механизмов сопоставления файловых масок различается: —— В Windows “*.*” – все файлы, в Linux:*.*” – все файлы, содержащие в названии точку —— Маски в Linux также регистрозависимы!

—— Расширенный синтаксис масок в Linux:

• * – любое количество (ноль в том числе символов, допустимых в имени файла

• ? – любой (ровно один) символ, допустимый в имени файла Linux – особенности файловой системы • Регистрозависимость

—— Файлы «file.txt» и «File.txt» – разные!

• Отсутствие буквенных обозначений дисков • Отсутствие возможности обращаться к сетевым ресурсам, используя UNC —— Только к заранее премонтированным

—— Либо сторонними приложениями (нет гарантии, что установлено)

• Другой разделитель пути: «/» вместо «\» —— Платформа работает корректно

– 100 –

• [ – класс символов. После открывающей квадратной скобки указывается последовательность символов. Соответствует любому из указанных символов. Можно указывать диапазон, используя «-». Описание класса символов завершается «]». Для указания «-» в качестве символа класса нужно указать его первым или последним символом. Если после «[« указан знак «!», то класс описывает все символы, кроме указанных

—— Новые методы

• ПолучитьМаскуВсеФайлы

• ПолучитьМаскуВсеФайлыКлиента • ПолучитьМаскуВсеФайлыСервера

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3»

На самом деле – это тоже интересно. Маска «Все файлы» и в Linux и в Windows означают разное. В Linux маска «все файлы», это просто «*». А для того, чтобы в Linux выбрать еще и скрытые файлы, которые начинаются с точки, надо поставить маску «.*». И таких особенностей достаточно много. Для этого мы, собственно говоря, все эти механизмы закладываем в платформу, чтобы вам об этом не заботиться.

Linux – шрифты, Поле HTML Документа • При разработке конфигураций рекомендуется —— Использовать стилевые шрифты

—— Либо, при необходимости, шрифты из состава MSCoreFonts —— Других шрифтов в разных ОС может не быть!

• Поле HTML Документа

—— В клиенте для Linux – используется WebKit

Работа с внешними устройствами и ограниченность в правах в Linux

—— В клиенте для Windows – используется Internet Explorer

• Другие принципы работы с оборудованием – важно для разработчиков внешних компонент

—— В веб-клиенте – тот браузер, в котором работает приложение (IE, FF, Chrome, Safari)

• Для разработчиков конфигураций также нужно учитывать особенности

—— Отображение страниц может отличаться в разных вариантах

—— Например, форма настроек внешней компоненты работы со сканером штрих кодов

—— При использовании свойства «Документ» не следует использовать специфичные для конкретного браузера методы и свойства. Только стандарт!

—— Настройка последовательного порта: • В Windows: COM1, COM2, …ит.д.

• В Linux: /dev/ttyS0, /dex/ttyS1,или/dev/ ttyUSB0, /dev/ttyUSB1… Зависит от используемого оборудования

• Ограниченность в правах в Linux

—— Работать с правами суперпользователя не принято

—— Обычный пользователь имеет доступ на запись только к себе в домашнюю директорию, и, как правило в /tmp

—— Остальная ФС – только для чтения (к некоторым ее частям вообще не может быть доступа) —— Для доступа к внешним устройствам – часто тоже нужны спец. права

• Например, в Ubuntu для доступа к последовательному порту пользователь должен быть в группе “dialout”

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

Linux – COM, OLE, ActiveDocument. Особенности клиент-серверного варианта работы • Технология COM, OLE и механизмы, их использующие

– 101 –

—— Не поддерживаются

—— Альтернатива компонентам по технологии COM – компоненты NativeAPI

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Возможности доступа из платформы к внешним приложениям и внешним приложениям к платформе (аналога COM) – пока нет —— Ближайший аналог «COM» для Linux – технология D-Bus, однако пока платформа ее не поддерживает

• Клиент-серверный вариант работы

—— Вызовы сервера не привязаны к определенному рабочему процессу —— Управлять «привязкой» вызова к серверу нельзя

Поскольку эти технологии на платформе Linux не работают – надо использовать открытые стандарты, интерфейсы, веб-сервисы, внешние компоненты.

Интерфейс 8.3 Такси

На самом деле, мы постарались сделать новый интерфейс более современным, более удобным.

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

• Интерфейс Такси —— Удобно

—— Комфортно

—— Современно

• Цели

—— Снизить порог вхождения —— Улучшить юзабилити

—— Предоставить разработчику конфигурации средства описания интерфейса с учетом специфики приложения

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

– 102 –

Все сосредоточено в одном окне.

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3»

Мобильная платформа 1С:Предприятие

Панели • Редактор панелей

—— В конфигураторе задается начальное расположение панелей —— Пользователь может изменить их состав и расположение «под себя» – такая идеология используется в «порталах»

Что важно? Вот это многообразие панелей, которое существует, теперь превратилось в многообразие компоновок.

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

• Новая технология работы «1С:Предприятие 8» на мобильных платформах —— iOS (iPad и iPhone), —— Android

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

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

Пример того, как все пространство, которое есть, отдано под информацию, с которой надо работать.

• Первое приложение на мобильной платформе партнеры разработали через 1.5 часа после публикации версии 8.3.2 • Некоторые сотрудники 1С уже используют мобильный документооборот (почту) на версии 8.3

• 20 декабря 2012 года выпущена бета-версия мобильного приложения 1С:Управление небольшой фирмой • 1 апреля 2013 года анонсирована бета-версия «1С:Монитор ERP»

Очень удобно! Я нахожусь на конференции и на планшете читаю почту в «Документообороте».

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

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

В одном обсуждении даже проскочила такая фраза «Мобильная платформа положит AppStore». Ну, действительно, представьте – на Инфостарте вас 300000 человек. Даже если только 3000 человек – 1% от сообщества, напишет по приложению, а их писать можно быстро, и выложит это все на AppStore, то им, наверное, придется отдельный клон под 1С делать.

– 103 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Важно! Можно существующие клиентские приложения быстро переделать для мобильной платформы. Есть специальные «мастера», которые подсказывают, где что нужно поправить для того, чтобы приложение было совместимо с мобильной платформой.

—— Независимое приложение. Может работать автономно.

—— Автономное рабочее место внешней ИС. Оно может синхронизироваться с Backend системой,которая где-то в облаке расположена. Причем, система необязательно должна быть написана на 1С – это может быть какой-то сторонний сервис.

—— Универсальное автономное рабочее место (любой тип клиентского места)

• Характеристики рабочего места

—— Для менеджеров, «полевых» сотрудников, отчетность для руководителей…

—— Упрощенная схема данных и интерфейс

—— Специальная функциональность мобильных устройств

Мобильная платформа 1С:Предприятие • Удобное и современное «1С:Предприятие» – персональный ассистент на Вашем мобильном устройстве

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

—— Для владельцев бизнеса —— Для руководителей

—— Для ТОП-менеджеров —— Для менеджеров

• Новые формы применения программного обеспечения —— Для ежедневного контроля бизнеса —— В любое время суток —— В любой точке мира

Характеристики мобильной платформы • Native приложение под ОС мобильного устройства. То есть, само приложение – это так называемое Native приложение, которое исполняется в среде. Оно использует элементы управления. Оно стандартное для мобильных устройств

• В то же время, туда заложен узнаваемый интерфейс и узнаваемая функциональность, которая присутствует в платформе 1С, что позволяет сочетать узнаваемый GUI и органичность приложения на мобильном устройстве Архитектура Мобильной платформы 1С • Аналог тонкого клиента с локальной БД. То есть, по сути, мобильная платформа – это аналог файловой базы данных на мобильном устройстве.

• Адаптированы технологии 1С:Предприятия для ПК • Интеграция с функционалом устройств.

• Клиент + сервер, а не просто мобильный клиент • Варианты разработки

– 104 –

Андрей Аристархов

Новые возможности платформы «1С:Предприятие 8.3» Разработка мобильного приложения Все просто. В свойствах конфигурации в свойстве «Назначение использования» ставите «Мобильное устройство». Можете поставить «Мобильное устройство и десктоп». Просто, если вы ставите «Мобильное устройство» – в конфигураторе отключаются те объекты конфигурации, которые не доступны на мобильной платформе, а так – все то же самое.

Функциональность мобильных устройств • Возможности мультимедиа (фото, видео и пр.)

• Возможности геопозиционирования (geolocation) и геокодирования. Кстати, это важно, geolocation с английского переводится как геопозиционирование. Потому что геолокация на русском (вы можете посмотреть в википедии) – это зондирование каких-то слоев земли без разрушения… – методом радиолокации. Поэтому, на русском языке правильно говорить «геопозиционирование».

• Использование встроенных карт устройства —— На iPhone – карты Apple

Доступные приложения • Управление небольшой фирмой • Монитор ERP • Заказы

—— На Android – карты Google

• Адаптация к размеру экрана

• Использованы элементы управления ОС мобильных устройств

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

Приложение Монитор ERP сейчас интегрировано с 1С:Управление торговлей.

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

– 105 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

1С:Документооборот на ладони • Новое решение на платформе «1С:Предприятие 8.3» • Используется сотрудниками 1С для работы

• Позволяет работать с почтой на мобильном устройстве • Работает автономно, периодически соединяясь с центральной базой • Поддерживает ОС iOS и Android

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

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

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

Заметки из Зазеркалья. Ресурс, где мы делимся информацией о новинках • Произвольные области в модулях для организации кода • Автоматическое сохранение настроек списков • Про multitenancy (Автор – С. Нуралиев) • Про профили безопасности

• Про новый пользовательский интерфейс • …

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

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

– 106 –

Построение информационной системы современного предприятия на базе СПО (свободного программного обеспечения) Федор Куликов ИТ-Прагматика, Сертифицированный специалист RedHat. Эксперт по эксплуатации 1С + Linux.

От ведущего: Задам вопрос залу: как вы считаете, можно ли полностью инфраструктуру предприятия построить на Windows? На самом деле нельзя. Дело в том, что такая аппаратная часть, как Cisco или роутеры D-Link внутри себя содержат ядро Linux. Ядра Windows в инфраструктуре сетевого аппаратного обеспечения нет. То есть, условно, системы всегда гетерогенны. Федор, у меня к тебе вопрос, который собственно Андрей Аристархов задал аудитории:«У кого сейчас 1С-ная инфраструктура работает на Linux?». Помнишь, там все сроками мерялись? Я сказал год. Кто-то сказал 4 года. У тебя сколько? От докладчика: Сейчас посчитаю. Собственно говоря, это была седьмая Fedora. Сейчас восемнадцатая. У Fedora релиз раз в полгода. Значит, это было пять с половиной лет назад.

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

Фонд свободного программного обеспечения В 1985 году появился фонд свободного программного обеспечения. На тот момент он занимался тем, что нанимал программистов, и писались программные продукты с открытым кодом. И передавались для дальнейшего развития.

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

Критерии свободного программного обеспечения

История возникновения Началось все с Ричарда Столмана. В 1983 году им была предпринята попытка создать проект GNU.GNU – это свободная Unix-подобная операционная система. Что нам это дает? Как получилось так, что мы пришли к использованию свободного программного обеспечения, в частности, Linux?

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

– 107 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 граммного обеспечения или компании-франчайзи. Я имею в виду конечных потребителей, их IT-отделы. Я десять лет руководил IT-отделом. И в один прекрасный момент бюджет на программное обеспечение составил 150 долларов. К тому моменту я и один мой коллега уже довольно хорошо разбирались с Linux. Более того, я и он уже поставили Linux себе на рабочие станции. И вот, одна из девушек, работающих в компании, зашла ко мне в кабинет, увидела третий KDE и сказала: «Какая у тебя смешная экспиха!» Тут-то меня и посетила мысль о том, что на сервера и рабочие станции конечным пользователям можно поставить Linux, потому что, как минимум, двум третям пользователям будет все равно, а проблема моего бюджета на программное обеспечение тем самым решится. Вот так – свободная лицензия, собственно говоря, мне и помогла первый раз.

Чтобы ориентироваться в свободном программном обеспечении – поясню. Свободное программное обеспечение свободному программному обеспечению рознь.

GNU General Public License (GPL)

Если вы обратите внимание, то Postgres публикуется именно под BSD лицензией и поэтому пользуется большой популярностью среди компаний, которые выпускают закрытый софт. А для проекта MySQL, который был выпущен под лицензией GPL, с тех пор, как Sun был куплен Oracle, тоже всячески стараются сделать код закрытым.

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

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

Свободное – не значит «бесплатное».

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

Berkley Software Distribution license

Есть два больших лагеря – сторонники GPL-лицензии, относящейся к проекту GNU и сторонники BSD-лицензии, относящиеся к университету Беркли.

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

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

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

• Самый простой из них – выпускать всякие символики, футболки, чашки, кружки…

• На этом тоже далеко не уедешь, поэтому – есть «заказная разработка».

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

– 108 –

Федор Куликов

Построение информационной системы современного предприятия на базе СПО

Portable Operating System Interface for Unix (POSIX)

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

Самый интересный такой момент – чем, по сути дела, является любой софт для конечного потребителя? Как вы думаете, софт сам по себе, как строчки кода, имеет ценность для конечного потребителя?

Я тоже склоняюсь к мысли, что почти любой софт является услугой. Ни свободный софт, ни закрытый софт ценности для конечного пользователя как сами функции не имеют. Если помните, есть такой мультфильм про дядю Федора из Простоквашино. Он там с Шариком спорит по поводу холодильника, который был взят напрокат: «Холодильник чей? Государственный. А холод, который он дает? Он наш. Ради холода мы его и берем». Все это я говорю применительно к «заказной разработке». Для небольших компаний, которые работают с небольшими клиентами, использование свободного программного обеспечения – это возможность удешевить проект, сэкономив на лицензиях на закрытый софт. То есть, они могут платить только за те продукты или «заказные разработки», для которых нет открытого софта, который бы удовлетворял всем необходимым потребностям в данном случае.

А как еще можно заплатить разработчикам – не платя денег?

• Можно вносить изменения в код и возвращать его обратно, то есть, делать патчи.

На тот момент, когда велась разработка проекта GNU – уже существовало множество программ, способных работать через интерфейс POSIX, но готового ядра к этому набору программ еще не было. Именно тогда Linux, разработку Линуса Торвардса, и приняли для разработки ядра операционной системы. Можно ли использовать какое-то другое ядро? Да. Можно использовать ядро от BSD-систем. И использовать те же самые программные продукты. Тот же самый GNUKDE и все остальное – они будут работать и работают как с использованием Linux ядра, BSD-ядра, Solaris… и так далее. Обеспечивается совместимость на уровне программного кода. Достаточно перекомпилировать программу с другим ядром – и мы получаем рабочую систему.

Linux дистрибутив

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

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

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

• У нас есть чудесное ядро. Даже несколько.

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

• К этому набору программ есть определенный доступ.

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

• Ну и, самое главное, есть инсталлятор.

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

– 109 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Критерии выбора дистрибутива для предприятия

У «долгоживущих» дистрибутивов – срок поддержки от пяти лет и выше. Ну, например, RedHatEnterprise поддерживается от пяти лет.

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

ИТ-сервисы предприятия

Такие известные дистрибутивы, как Fedora, Debian, Mandriva – содержат от 15 до 30 тысяч пакетов. И, если во всем этом разобраться, то, наверное, мы найдем все, что нам нужно для построения этой инфраструктуры. Как подходить к выбору дистрибутива?

• Поставка. Как я уже говорил – свободный не значит бесплатный. То есть – надо выбирать дистрибутив, который имеет высокую степень поддержки, хорошую инфраструктуру, и им пользуются. Например, есть очень хороший платный дистрибутив RedHatEnterprise. Несмотря на то, что он платный, этот дистрибутив остается свободным. Скомпилированной программы вы не получите, но исходный код – получить возможно. Отступая от темы – именно этим и воспользовался Oracle.

OracleLinux – это не что иное, как перекомпилированный RedHatLinux с убранными логотипами и всеми теми разработками, которые публиковались по GPL-лицензии.

• Поддержка. Стоимость поддержки дистрибутива RedHatEnterprise официальным вендором довольно дорога. Одна рабочая станция начинается от 140 долларов примерно в год. Сервер – от 3000 долларов в год.

Базовые сервисы – те, которыми пользуются все – и пользователи о них даже не знают

• Управление сетью TCP/IP. Это те низкоуровневые протоколы TCP/IP, без которых системные администраторы жить не могут, а конечным пользователям они неинтересны

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

• Файловое хранилище потребуется для документов • И т.д.

Linux и сеть Internet

Поддержка 24/7 стоит еще дороже. Если такая поддержка не нужна, но уж очень нравится то, что делает RedHat – можно воспользоваться пересобранным дистрибутивом, совместимым с RedHat-ом на бинарном уровне, например –CentOS. Полностью совместимо с RedHat, можно даже подключать RedHat-овские репозитории, и, соответственно, наоборот – будет работать.

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

RedHat-ом поддерживается два дистрибутива – RedHatEnterprise и Fedora. У Fedora срок поддержки – год. Частота выхода дистрибутива – раз в полгода. Замучаешься обновляться. А через год, не будет обновлений и, в случае какой-то «дыры», либо самому разбираться с этим, либо переходить на что-то другое.

С сетью все хорошо. Как известно, CISCO отказалась от своей операционной системы в выпускаемой ею линейке сетевых устройств Linksys. Поэтому там спокойно крутится ядро Linux со всеми вещами, имеющими отношение к маршрутизации – фаервол, Apitable… И там все то же самое, что мы видим на больших серверах. Если вы когда-нибудь администрировали маршрутизацию протоколов, то попав в Linksys роутер, вы очень быстро откажетесь от веб-интерфейса и будете работать с теми же самыми утилитами, что и в большом дистрибутиве.

– 110 –

Федор Куликов

Построение информационной системы современного предприятия на базе СПО

Служба каталогов Оказывается, у ActiveDirectory существует много альтернатив.

Перечислим только самые известные:

• Ныне почивший Sun разработал целых два продукта службы каталогов: NIS и NIS+. Несмотря на одинаковость названий – это разные службы каталогов по своим возможностям.

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

• Ну и такая служба каталогов, как LDAP.

—— Собственно говоря, началось все тут с фирмы Netscape – тоже уже ныне не существующей, у которой была разработка NetscapeDirectoryServer – которая долго «кочевала» из рук в руки. Одним из известных его правообладателей был AOL. И в 2005 году был куплен RedHat-ом – и то, что возможно было опубликовать под свободными лицензиями, было опубликовано. Так получились такие серверы каталогов, как:

• NetworkFileSystem (NFS)– протокол сетевого доступа к файловым системам, первоначально разработан SunMicrosystems. Исходный код был раскрыт. Классическая клиент-серверная схема – собственно говоря – все файловые хранилища, они по этой схеме и реализованы. Теоретически поддерживается Windows. Изначально присутствовало в NT – было, работало, пробовал. В 2000 тоже было. Vista как-то мимо прошла – а в Win7 доступен только с версии Ultimate (из Profее убрали). Что в 8-ке – не знаю, пока не щупал. Но, собственно говоря, тенденция настораживает.

• Server Message Block (SMB) / Common Internet File System (CIFS) – разработка компании Microsoft. В Linux поддерживается пакетом программ SAMBA. Это – противоположный случай. Эти протоколы разрабатывались в Microsoft. И были ею, как считается – под давлением европейского сообщества – раскрыты. На данный момент функционирует две ветки – это SAMBA третья и SAMBA четвертая.

—— В третьей SAMBA есть доступ к файлам, каталог печати и средство авторизации.

—— В четвертой SAMBA – это, наверное, ее имеет смысл упоминать в разделе «Центральная авторизация». Потому что это тоже такая большая система, похожая на FreeIPA – с одной стороны, где пытаются реализовать центральную авторизацию, опять-таки, используя LDAP. А с другой стороны – все это «дружит» с DNS/DHCP сервером,и получаем в итоге службу каталогов, совместимую с ActiveDirectory.

—— RedHatDirectoryServer

—— Mandriva Directory Server – клон Red Hat Directory Server

—— То, что нельзя было раскрыть в силу лицензий – было переписано. Итак, появился FedoraDirectoryServer или 389 Directory Server, который сейчас встречается в большей части дистрибутивов.

—— Ну и такой большой проект FreeIPA, который включает в себя, кроме самих каталогов LDAP, еще DNS, DRCP и другие сетевые службы. Теперь это модно называть «облаком»

Файловое хранилище

Файловые помойки на предприятии – это «притча во языцех» – чего там только нет. От полезных документов и заканчивая египетскими фотографиями. Как известно, места там всегда не хватает. Будем устраивать файловую помойку в Линуксе. Что есть здесь у нас?

• File Transfer Protocol (FTP) – протокол передачи файлов. Свободные реализации сервера ProFTPD и VSFTPD. Банальная вещь, всем известная. На всякий случай рассказываю – тоже поддерживается.

• SSHFileTransferProtocol (SFTP) – используется SSH (SecureShell) для передачи файлов, шифруются команды и файлы. Это такая универсальная штука, такой «швейцарский перочинный армейский нож». Тоже может использоваться как протокол передачи файлов SFTP для тех, кто за «секьюрность». Потому что файлики при передаче шифруются. На самом деле – SSH еще можно использовать в качестве других интересных вещей. Например – как туннель для X-сервера.

– 111 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Служба печати

• Есть еще такой Interbaseserver – родом из Борланда. Был открыт исходный код шестой версии, и получился Firebird – сервер баз данных. Он часто используется в проектах, которые написаны на Delphi.

Учетная система

Здесь у нас есть CommonUNIXPrintingSystem (CUPS) – сервер печати для UNIX. По сути дела – это система управления очередью. Его можно использовать не только для целей печати документов, но и для отправки факсов и любых других очередей. Например, Fax4CUPS легко заменяет факс-сервер в компании. Правда, на данный момент это уже неактуально, поскольку факс уходит в прошлое.

Базы данных

Тут – распространяться не будем. Возлагаем надежды на 1С – на версию 8.3.

Почтовая служба

Тут тоже большой выбор.

• PostgreSQL – реляционная СУБД. История развития началась в 1986 году в университете Беркли. На данный момент распространяется под лицензией BSD. Характеризуется надежностью и отказоустойчивостью, поддерживает базы неограниченного размера. Самая любимая разработчиками БД, когда есть необходимость закрывать код. Что я могу сказать? Лично использую эту базу данных в проектах, даже предпочитаю эту базу данных MySQL, поскольку она универсальна, годится как для учетных систем, так и для веб-проектов.

• MySQL – изначально разрабатывалась компанией MySQLAB как легкая СУБД, ставка делалась на скорость. Собственно говоря – Oracle покупал SunMicrosystems ради JAVA, но тут ему еще такой подарок в виде прямого – пусть небольшого – но конкурента своей собственной базе данных. Поэтому – изначально, когда был раскрыт исходный код MySQL – он распространялся под двумя лицензиями – под закрытой проприетарной и под открытой GPL. —— Если кто еще интересуется или занимается веб-разработкой и посещает конференции, относящиеся к веб-разработке – то там, в основном – про MySQL можно уже и не услышать. Там будут MariaDBи другие форки MySQL.

Почтовая служба – до сих пор – одна из тех вещей в Линукс, которая сохранила Unix-way.

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

• Есть MailTransportAgent (MTA), который занимается только тем, что доставляет почту от одного сервера к другому. Здесь sendmail, postfix, exim… В моих любимых RedHat-дистрибутивах даже есть небольшой скрипт, который позволяет «на лету» менять MTA для сервера. То есть – осуществлять выбор между двумя утилитами в поставке – sendmail и exim. Вот их можно менять в зависимости от вкуса, цвета и предпочтений.

• Internet Massage Access Protocol (IMAP). Есть два протокола – IMAP и не упомянутый здесь POP3, которые уже доставляют почту конечному пользователю. Опять таки, два наиболее известных – на слуху – это dovecot и cyrus.

• Спам. Со спамом, опять же – можно бороться открытым программным обеспечением – это

– 112 –

Федор Куликов

Построение информационной системы современного предприятия на базе СПО

Spamassassin – использует Berkeley алгоритмы. Если его правильно натренировать – очень хорошо работает.

• Антивирус тоже есть под свободной лицензией – ClamAV. Такая парадоксальная ситуация – написан под Unix. Борется с Windows-вирусами.

Организация дистанционной работы сотрудников

• X-WindowSystemcoreprotocol (X-протокол) – это сетевой протокол работы с окнами – с оконными менеджерами. К нему можно иметь доступ по сети, как с использованием RAW-сокетов, так и протокола TCP/IP. То есть – для того, чтобы организовать удаленную работу сотрудников – практически больше ничего не нужно. Единственный минус – не сохраняется сессия пользователя. То есть – если сессия разорвалась – то все данные в сессии будут потеряны.

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

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

• Вторая причина – повышение масштабируемости. Если вы помните 1С:Предприятие 7.7 – то масштабируемостью она никак не отличалась. Вот и был придуман такой «хитрый способ». Собственно говоря – задача стояла заставить работать одновременно 120-130 пользователей. Официального решения на это не существовало. Проблема заключалась в том, что – как ни оптимизируй код – семерка без всяких тайм-аутов ломится в базу, стучится туда и стучится. К тому моменту мы уже использовали виртуализацию – это теперь называется «облачные технологии» – был XEN. И еще – нас спасло несколько серверов приложений, правда 2003-х, которые были запущены в виртуалках, и между ними были распределены пользователи. Как ни странно, это дало облегчение. Система стала работать гораздо быстрее за счет распределения таких вот нагрузок по разделенным серверам. Причем – лучше даже, чем loadbalancing в citrix-е.

Немножко лирики. Как можно было использовать 1С до появления 8.3 и до появления сервера приложений под Linux?

Собственно говоря – компанией Etersoft разрабатывалась коммерческая версия WINE. Это WinAPI функции для Linux.

И – с помощью нее семерка довольно стабильно под WINE-ом работала. На данный момент – как вы помните – 1С:Предприятие 7.7 работает только с MicrosoftSQLServer 2000. Поддержки MicrosoftSQLServer 2000 сервера начиная с версии WINE2008, и, тем более под версией WINE2012, нет. То есть – 1С:Предприятие 7.7 под WINE работать будет только в файловом варианте. Как же выйти из этой ситуации тем, кому это необходимо? Есть продукт у Etersoft – EtersoftPostgres, который транслирует запросы MicrosoftSQLServer в запросы Postgres. И, таким образом – можно эксплуатировать старые седьмые базы без откатывания на старый софт.

Причины перехода на СПО

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

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

– 113 –

Когда сотрудник становится гаджетом Андрей Акулов Генеральный директор ООО «Вертер. Сенсорные технологии»

От ведущего: Мне вот интересно, допустим, я понимаю, что у меня заканчивается «продуктив», и я становлюсь «нажимателем кнопок», – у меня же может в этот момент произойти это внутреннее осознание, я же могу остановиться и сказать – «Что же я делаю? Так дальше нельзя!» – и поменять ситуацию. Разве обычно это редко случается? От докладчика: Обычно, когда берешься за проект и заходишь с этим проектом на предприятие, ты сталкиваешься уже с тем, что люди привыкли и не хотят ничего менять. В моем опыте ни разу не было такого, что «Ой, е-мое, мы же совершенно неправильно работаем. Давайте мы переоценим свою собственную работу и начнем по-другому». Никто не стремится взглянуть на ситуацию со стороны, никому не интересно рефлексировать на эту тему. Я хочу с вами поговорить о бизнесе. О том, как продавать те знания, которыми вы обладаете, на проектах конечным покупателям. И, в конце концов, заработать себе деньги.

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

Мой путь от программиста до предпринимателя

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

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

План доклада

Итак, давайте мы сосредоточим свое внимание на четырех главных группах – это • Заказчик и его сотрудники

• Анализ бизнеса клиента – это когда вы пришли к клиенту и вам нужно решить «Что делать?»

• Управление проектом – сама команда управления.

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

Работа с заказчиком Это я. Это мои 10 лет работы в разных компаниях, начиная от компаний-франчайзи. Компании, где я работал, периодически менялись, появлялись ИТ-интеграторы, мультивендорные компании. Соответственно, проекты росли, проекты становились сложнее.

Существует три глобальных мифа о работе с заказчиком, которые нам мешают:

• Первый миф – Владельцу компании нужны инновации, модернизации, оптимизации, консультации – все эти окна с красивыми иконками и т.д.

– 114 –

Андрей Акулов

Когда сотрудник становится гаджетом

Позже я расскажу историю о том, как мне показали, что это не совсем так.

• Второй миф – Техническое задание должны писать сотрудники Заказчика. Мы почему-то ждем, что нам наши заказчики сами дадут какое-то техническое задание. То есть, мы ждем, что они к нам придут и скажут, что нам надо сделать.

• Третий миф – Сотрудники Заказчика обязаны знать такие понятия, как регистры, версии, релизы, метаданные. Они должны понимать эту программу. Они должны пройти курс обучения. Они вообще уже все должны быть готовы, на самом деле, к нашему приходу. Мы же, такие мессии, к ним пришли, а они не готовы. Что с этим делать?

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

Миф первый. Заказчику нужны инновации, модернизации, оптимизации, консультации • Итак, возьмем 2008-2009 год, когда кризис наступил. В качестве компании возьмем производственную компанию, с полным циклом жизни изделия – закупка материалов, производство, склады по всей России, продажи и так далее. Меня вызывают и говорят: «Предложи способы или создай условия для того, чтобы можно было как-то сократить людей». Ход моих мыслей: «Так, бюджеты под это вы мне не даете, значит, я никого привлечь не смогу. Давайте подумаем, что мы можем для этого сделать».

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

• Но у меня в тот момент возник достаточно резонный вопрос, и я говорю владельцу этого бизнеса: • Иван Иванович, объясни мне, пожалуйста, почему раньше, когда были «сладкие времена» вы этой оптимизацией не занимались? Ведь то, что мы сделали, это довольно просто. Это можно было делать в спокойные времена, не особо напрягаясь. И всей этой гонки бы не было. Он мне на это говорит:

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

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

Миф второй. Техническое задание должны писать сотрудники заказчика.

• Ну, во-первых, ТЗ читают в арбитраже, если вы знаете. То есть, если вы ТЗ написали с ошибками, вам будет очень трудно сдаваться по такому ТЗ. Например, в ТЗ написан такой простейший текст: «У программы должен быть удобный интерфейс». Вы пропустили в свое ТЗ такое требование. Как вы будете сдаваться по такому ТЗ? Какие критерии у этого удобства? В результате, когда вы формируете ТЗ, нужно смотреть на те слова, которые вы пишете, и максимально все детализировать с расчетом на то, что вы, возможно, встретитесь с этими клиентами уже в арбитраже.

– 115 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

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

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

• Здесь мне сразу вспоминается пример из практики моей работы начальником отдела ИТ, когда мне пришла такая заявка: «Просим нам, бухгалтерам, на каждый из десяти столов в бухгалтерию поставить по планшетному сканеру». Конечно, вроде все понятно. Но возник вопрос – а зачем десять сканеров? Пришел к ним говорю:«Объясните мне, а для чего вам нужен сканер?» Оказалось, они в 1С делают накладную, дальше ее копируют, вставляют в Excel, добавляют строчки подписи, распечатывают, ставят печать, подписывают. Потом бегут на первый этаж, там сканируют. Потом бегут обратно на второй этаж, из папочки забирают фотографию этой накладной и уже в таком виде отправляют ее дальше на склады. Это к вопросу о некомфортности – им надоело месяцами на первый этаж бегать, поэтому они решили, что им сканер на рабочем столе нужен. Соответственно, вопрос. Что здесь можно улучшить, даже не прибегая к нашим супер-мега способностям, как программистов? Самое простое – можно отсканировать подпись и печать и в том же Excel их вставлять. Конечно, мы потом им это в 1С сделали, что можно просто нажать кнопку и накладная сразу уходила с подписью и печатью – они были такие счастливые. Хоп – уже снизились ваши затраты, да? Не потребовалось никаких сложных разработок, тестирования, оптимизации вашего кода. Надо было всего лишь внимательно посмотреть, чем занимаются ваши люди.

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

В результате нарисовался такой график.

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

А точка С – это, когда вы сделали ряд мероприятий по автоматизации работы, в результате которых у вас очень сильно возросла производительность и очень сильно упали требования к персоналу. Здесь возникает «слом модели». Люди поняли, что работать стало проще. Состав коллектива поменялся. Вновь вышедшие попали на ситуацию С, когда система уже заработала, проблемы решены, большинство операций автоматизировано. Эти люди не знают, как система работала раньше. Они видят только то, как система работает сейчас. Вообще, люди обычно любую систему воспринимают через интерфейс. Поэтому именно над интерфейсом нужно думать в первую очередь. Как о том, с чем будет работать ваш конечный пользователь, конкретный человек, под которого вы пишете свое решение. Что происходит дальше? В некоторый момент, когда возникла какая-то не очень хорошая ситуация, и вы выявляете эту ситуацию, то вам говорят: «Это не я, это программа так выдала».

– 116 –

Андрей Акулов

Когда сотрудник становится гаджетом

Спрашивается: А ты что тут делаешь? Ты не можешь подумать, что в печатной форме у тебя что-то не то напечаталось? Ты не можешь проанализировать, что должно быть не так? Ты не можешь пойти сказать об этом? Не получается. Вот эти девушки – они превращаются в таких «гаджетов», почему и тема так названа – «Когда сотрудник превращается в гаджет». Это происходит в момент, когда сотрудники заходят в систему на точке С и там начинают с этой системой работать.

Как вы видите, во всем этом 1С даже и близко нет.

1С у нас выступает как инструмент. А здесь рассматриваются немного другие вещи. Давайте поговорим на эту тему.

Метод «Следование за заказом».

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

Анализ бизнеса клиента

Итак, мы посмотрели заказчиков, посмотрели сотрудников. Теперь давайте посмотрим ситуацию, когда вы зашли на предприятие. Что нужно делать в этот момент? Можно применять Agile-технологии, можно применять PMBoK, можно применять Lean-технологии, можно еще какие-то технологии применять… Все это красиво звучит, но на практике, чтобы это сделать, нужно столько мозгов туда потратить. И, тем более, когда отсутствует пошаговая инструкция, это иногда бывает проблематично. Поэтому, в любом случае, начинать надо с простых, не затратных вещей.

• Во-первых, я предлагаю использовать метод «Следования за заказом», о котором я немножко уже упомянул.

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

• И, собственно говоря, третий этап – это создание психологических якорей.

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

• Дальше – обращайте внимание на действия сотрудников. Как они работают. Выявляйте симптомы проблем. Для того чтобы выявлять симптомы проблем, к сотрудникам заказчика надо сначала найти подход. Вот как вы будете общаться с ними? Авторитарно – «Скажи мне, как ты работаешь?» Или, может быть, как-то более мягко? Может быть, подойти не сразу «в лоб», а просто пообщаться, чай вместе попить, конфетками их немножко задобрить… Может быть, имеет смысл на этом этапе немножко поработать? То есть создать нормальные отношения. В результате у вас возникает такая ситуация, когда вам начинают жаловаться. Точнее, все-таки не жаловаться, а рассказывать о своих бедах. У каждой компании много бед. А у сотрудника, который там работает, этих бед еще больше. Для вас это первый знак того, что вы должны это брать «на карандаш». Но при этом не надо все их беды «брать на карандаш». Вы там приходите, они же вам все рассказывают – о своей семье, о своих мышках, о своих собачках, о начальниках, о знакомых… Фильтруйте этот мо-

– 117 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Вы обнаружите, что для того чтобы раскроить какую-то деталь, рабочему нужно пойти в соседний цех, потом вернуться обратно, и уже дальше обработать деталь. 1С тут нет. Нужно просто посмотреть, чем занимаются ваши рабочие непосредственно на производстве. Желательно посмотреть в глаза этому рабочему, поспрашивать его, почему он именно так делает. Поговорить с мастерами, с начальниками производства, которые там работают. Неужели они этого не видят? Того, что вам прямо бросается в глаза. В результате, вы выявляете, что 60% муд – это потери времени на хождение, на ожидание, на то, что материала нет и т.д. После того как мы неделю с нашими нормировщиками и аналитиками эту сплошную фотографию рабочего дня делали и потом выкатили эти результаты – начальство очень удивилось. Дальше начался очень интересный процесс – мы начали прямо как в тетрисе станки переставлять. Начертили схему цехов, нарезали из бумажки квадратики, и стали их расставлять. Ну и дальше в течение месяца это на практике все расставлялось. Тут же соответственно производительность выросла.

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

• Дальше – когда вы собрали этот массив информации, его надо классифицировать. Неважно, в какой форме. Не надо здесь сложные системы сразу внедрять. Обычный карандаш, обычный Excel, Word или даже просто стикеры, которые вы наклеиваете. Итак, классифицировали, определили наиболее явные зоны проблем. На самом деле, для того, чтобы пройти по крупномасштабному предприятию, нужно всего два дня. И три дня на обработку. В результате у вас получается срез проблем, с которыми дальше уже можно работать более конкретно.

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

• Ну и собственно – «История про муда». Вот вам вчера рассказывали, что есть такое понятие «муда», которое означает потери времени. Но вам не рассказали, а как же этих муд выявлять. То есть, вроде как есть некая технология Lean. Она замечательно звучит. А вот где же эту «муду» найти, вам не сказали. А я скажу. Ситуация обратная – людей посокращали на производстве, и тут заказы пошли. Производство стало не справляться. Что делать? Заказы стали стопориться, клиенты ругаются… Как вы понимаете, на этом этапе от 1С никакого толку не будет, какая бы она супер-мега-крутая не была. Надо понять, в чем причина. Опять-таки, топайте на производство ножками. И, в момент, когда на производство подается какое-то сырье – например, массив дерева (такой кругляк), берете секундомер и встаете рядом с рабочим, который его пилит, и дальше, не выключая секундомер, ножками идете за этим рабочим его тайными тропами. И таким образом, записываете длительность каждого этапа по каждому из видов продукции, которые этот рабочий выполняет. В результате, вы обнаружите, что процентов 60 своего времени рабочие просто ходят. То есть, 60% времени – это и есть эта «муда». Вот, он от одного станка идет к другому. Пришел, ждет, пока освободится этот станок. Взял детальку, положил в тележку – пошел обратно. Опять ждет. Вот у него два цеха – один цех, второй цех – маленькая такая ступенька. Ему приходится тратить время на поднимание этой телеги и опускание ее, только потом он будет дальше двигаться. Вы увидите, что станки, которые у вас стоят на производстве, стоят неоптимально.

Налаживание контакта с рядовыми сотрудниками заказчика

• Берем сотрудника. Это живой человек. Это не ресурс. Меня всегда в компаниях смущало то, что есть «ресурсное планирование». Звучит, конечно, классно: «Мы пошли заниматься ресурсным планированием». Но это живые люди со своими проблемами. Поймите, что у него за проблема. Поговорите с ним. Посмотрите, что у него стоит на столе. Вот вы, когда ездите отдыхать, привозите оттуда какие-нибудь сувениры, они у вас на столе стоят? Для чего вы их там кладете? Чтобы, наверное, кто-нибудь пришел и задал вам вопрос «Какая замечательная штучка и зачем она у вас тут лежит?». Если кто-нибудь придет, вы ему на полчаса выскажете информацию об этой штучке, как вы ее покупали и так далее. Вот, уже тема для разговора. Фактически, когда вы заходите на предприятие и видите сотрудников, обращайте внимание

– 118 –

Андрей Акулов

Когда сотрудник становится гаджетом И мне отвечают – «Мы к ним не ходим принципиально. У них там плохо пахнет». Ну что тут еще можно сделать в этом плане?! Вот такие вот бывают ситуации.

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

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

• Дальше. Личное знакомство. Ну, все-таки, заходите вы на проект не на один день, а на несколько месяцев. Поэтому – выстраивайте отношения с сотрудниками вашего клиента заранее. Интересуйтесь ими. Смотрите, что у них на столе. Пример приведу. У девчонки на столе стоит обычная фотография котика. Я ей говорю – ой, какой у тебя замечательный котик. Он, наверное, у тебя дома бегает. Она отвечает – нет, это моя мечта. Я хочу такого вислоухого британского котенка. А я ее первый раз вижу – как раз впервые всех сотрудников обходил. Я ей говорю – оставь мне свой телефон. Вдруг у меня в Москве этот вислоухий образуется, и я тебе его привезу. Как вы думаете, что я дальше сделал в Москве? Ну, понятное дело, я провел ряд мероприятий, чтобы найти этого вислоухого, но ей об этом не сказал. В результате, когда я ей через неделю привез этого котика, у меня на ближайшие три месяца вообще проблем с этим отделом не было. Как вы думаете, они мне акты подписывали? Понятно, что вы выстраиваете новую систему. Понятно, что на первом этапе эта система несовершенна. До оптимизации, которую Вячеслав с Андреем Гилевы делают, вы даже близко не дошли. Вам сейчас надо хотя бы скелет сделать работающий. В результате у вас возникают шероховатости. И либо вам помогают на этом этапе сотрудники, либо они вам не помогают.

• Ну и, ребята, личная гигиена. Это обязательно. Белье менять каждый день. Рубашки стирать через день. Толстовки – ну, хотя бы раз в неделю. Смех-смехом, но, когда я прихожу в отдел и говорю «Что вы к нашим программистам не обращаетесь?»

Создание психологических якорей.

Что имеется в виду? Опять-таки, я сейчас не советую, я рекомендую, потому что это работает.

• Вы, когда приходите на предприятие, имейте при себе сладости – шоколадки, конфетки – самые обычные, «Вдохновение» – они стоят 100 рублей. Из своего кармана возьмите, для этого не надо вашего руководителя проекта напрягать, чтобы он из бюджета эти деньги находил. Ну не нашел, да бог с ним! Вам же работать на проекте. Принесите эти конфетки, разнесите их по отделам, попейте чай с этими ребятами – они вам столько информации выдадут! А вы же с этим и работаете!

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

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

• Расскажу историю про клоунов. Я приехал на производство, принимать отдел. Говорю – мне с вами надо решить три вопроса. Во-первых, теперь, каждое утро, приходя на работу, вы просто будете обходить ваш отдел. Там комнат немного – шесть штук всего. Их обойти-то за 10 минут можно.

– 119 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Разделение труда в команде.

Просто заходите, здороваетесь, говорите «Как дела?», и идете обратно к себе. Я думал, это такая плевая идея – поставил галочку и пошел дальше, следующие вопросы решать. Нет. Мы целый час обсуждали эту тему. Я им пытался объяснять, ребята, ну это в ваших интересах. Нельзя сидеть перед монитором и ждать, что вам пришлют заявку. А если вы один раз обхамили этого сотрудника, ну, случайно обидели. Как вы думаете, он вам напишет какую-то заявку? Не напишет. В результате, мне не удалось их на это дело сподвигнуть. Они мне ответили вот так вот «Мы что, клоуны, ходить по отделу?» Так они и сидели. Ходил я.

Управление проектом.

• Самый простой вариант «Программист – заказчик». Это когда вы работаете на предприятии, и вы, как программист, решаете консультационные вопросы, консультируете, решаете, программируете…

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

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

• Дальше – документация проекта, которую вы готовите.

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

• Ну и, собственно, один из вопросов, который я не мог не поднять – это, извините, «Война полов». Когда на проекте работают ребята, девчонки, со стороны заказчика и со стороны клиента – и что между ними происходит. Всякое бывает. Иногда союз, иногда война. Я вообще считаю, что это тема отдельного доклада. Если кто-нибудь ее разовьет, я думаю, популярность будет.

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

• Иногда бывает еще сложнее – когда еще часть архитектора делится на архитектора системы и технического архитектора.

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

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

– 120 –

Андрей Акулов

Когда сотрудник становится гаджетом

время? Или расшифровку этого интервью можно было отдать на аутсорс?

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

Документация проекта.

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

• Дальше – инструкции. Инструкции мы все время пишем. Это довольно противное занятие, но его делать надо. Как выглядит идеальная инструкция? Вспоминаем плакаты ГО и ЧС. Или вспоминаем самолет, когда нам надо провести эвакуацию. Вспоминаем комиксы. Вот она, инструкция. Но, чтобы такую инструкцию подготовить, нам необходимо провести комплекс мероприятий по анализу процессов, по их описанию, по регламентации и т.д. и т.п. И только потом, на конечном этапе, вы выводите эту инструкцию, красивую, с картинками. Например, отдел качества. Сидит девушка, которая должна поднять телефон и сказать «Добрый день! Меня зовут Марина, компания такая-то. Чем могу быть полезна? » Вы так в этой визуализированной инструкции и рисуете: девушку, которая улыбается, которая поднимает трубку, и говорит вот этот текст, чтобы она его видела и понимала, что от нее требуется. Обычный текст они читать не будут. У меня не читали. Может, у вас читают.

• Дальше. Внимание к деталям. Простейшая ситуация. Берем схему процесса. Берем ее описание. Берем ссылку на этот процесс где-нибудь в документе. Желательно, чтобы наименования этих процессов были одинаковы. И обязательно проверяйте перед отправкой те документы, которые вы сдаете вашим клиентам.

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

• Каждый документ – берете его, смотрите. Ошибку одну нашли – всем, кто подписал документ, штраф 1000 рублей. Можно чуть больше – 100 баксов. Когда я работал в компании, которая занималась тем, что описывала бизнес-процессы, с меня и моих коллег брали штраф за ошибку – 100 баксов. Мы тогда готовили такой большой пакет документов – схемы, описания, инструкции, примеры и т.д. И если президент компании находил хоть одну ошибку – все, кто подписал, получал штраф 100 баксов. Соответственно, после третьей-четвертой итерации ты уже смотреть не мог на эти документы. Ты уже настолько их выверял… Сразу скажу, надолго меня в этой компании не хватило. Но зато теперь, когда я на проекты прихожу, я уже сразу вижу те ошибки, которые делают другие сотрудники.

Пресейлы, презентации, сдача проектов, тендеры

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

• Вообще говоря, перед тем, как выйти на некий тендер – сначала нужно попасть на эту компанию, чтобы понять, что им нужно «изнутри». Потому что один человек на запрос: «Приезжайте к нам, покажите нам возможности УПП» – будет просто

– 121 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 ехать и показывать. А другой – сначала съездит на предприятие, поговорит с ключевыми людьми, тем более, на это много времени не надо. И, соответственно – уже на презентации будет проговаривать тот текст, который от него ожидают. Это первый вариант.

• Второй вариант – сделайте из презентации какое-то шоу. Не просто текст. Не сидите, уставившись в компьютер. Компьютер здесь, зал где-то там и вы читаете. Замените текст картинками.

• На самом деле – банальная раздатка. Надо раздатку иметь обязательно. Потому что на это мероприятие тоже приходят сотрудники вашего клиента. Им тоже скучно. Им хочется в руках что-нибудь потеребить. А они сидят, ничего не делают. Они на вас смотрят. А если вы еще и скучное что-нибудь рассказываете, то они вообще ничего не понимают. А раз им скучно, они еще и негатив копят к вам. Дайте им хотя бы картинки какие-нибудь красивые посмотреть, пусть они хотя бы их полистают.

Внутренний мир внедренца

• У меня есть знакомые, те, которые для себя решили, что хватит заниматься проектами. Сколько уже было этих проектов, сколько мы их уже сделали, сколько мы их еще будем делать. И они решают: а давайте-ка мы перейдем, например, в продажники. Хоть какое-то разнообразие. А некоторые говорят – да мне вообще все это надоело, я пойду дом строить. И уезжают дом строить.

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

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

Собеседования и ошибки компаний при общении с кандидатами

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

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

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

– 122 –

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

Андрей Акулов

Когда сотрудник становится гаджетом тому что завтра это сыграет против вас. То есть, если вы берете специалиста под проект, поговорите с ним, подо что вы его берете. А если у вас проектов нет – ну зачем его смущать-то?

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

Готовы что-то менять?

—— Дальше. Анкету ладно, все-таки дали, но не пишите таких слов «Укажите болезни, которые помешают вам работать в нашей компании». Ну что за бред?

—— Дальше. Что еще возникает у нас на собеседовании? Вот я, на самом деле, роль кадров в этом деле вообще свел бы к минимуму. И оставил бы на них только – встретить и провести к руководителю отдела. И не портить отношения с потенциальным кандидатом. Подумайте над тем, где вы их встречаете, в какой переговорной. Кандидаты же ходят в разные места, и в разных местах их встречают по-разному. Если крупная компания их встречает в маленькой переговорной и в этой переговорной грязно, а его еще не угощают, а у него 10-летний опыт. Вот у вас 10 лет опыта. Как это так – вы пришли на собеседование и вам кофе не предложили! Это что такое! Вы же уже наработали себе некую репутацию, а тут подвергается сомнению, что вы профессионал! Вам тут еще дают какие-то тесты, которые составил непонятно кто, и вы еще на эти тесты должны отвечать. Ребята, да я уже кучу проектов за эти 10 лет сделал! Поговорите со мной о тех проектах, которые я делал! Зачем от меня ограждаться этими тестами?

• Анекдот про HR: HR–директор умирает, попадает к Архангелу Михаилу. Архангел Михаил говорит: у нас сейчас новый порядок. Соответственно, сейчас у нас есть выбор. Ты можешь выбрать либо рай, либо ад. HR-директор говорит: «ого, как прикольно, ну давай я рай выберу». Ему Архангел Михаил на это говорит: «ты сначала сходи туда, посмотри, как в раю, потом денек в аду побудь. А потом придешь и выберешь». Значит, тот в рай приходит – там все красиво, на облачках играют арфы, все цивильно. Потом попадает в ад – там его встречают его друзья, HR-директора. Они его приглашают поиграть в футбол. Они целый день развлекаются – никакого подвоха вроде нет. Тогда HR-директор идет обратно к Архангелу Михаилу и говорит – «Знаете, я тут подумал. Наверное, я все-таки выберу ад. Там все-таки все уже знакомые, там так интересно – давайте-ка я туда пойду». Архангел Михаил ему говорит «Ну, как хочешь». Спускаются на лифте в ад, там пустырь, бумажки летают, котлы варятся. В котлах его же друзья сидят. HR-директор в ужасе «Как же так произошло?» Ему объясняют: «Понимаешь, вчера было собеседование. А сегодня уже работа». Поэтому, не надо гнать сказки на собеседовании и рассказывать, какая вы крутая компания. По-

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

Обратите внимание – 124 участника. 124 человека, которые уже работают в разных компаниях, которые приносят этим компаниям деньги, и эти люди теоретически готовы сорваться и пойти на этот проект. Взяли только восемь. Что они будут делать с этими 124-мя, я не знаю. Мне кажется, это отдельная тема для разговора. Я думаю, что если компании начнут в этом плане что-то придумывать, то рынок будет интересно меняться.

Мой выбор. Я – предприниматель!

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

– 123 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 смотрел, что появляются новые технологии, Windows Azure.

Тут предпосылка какая – вы можете как угодно относиться к слову стартапер. Мне оно тоже не нравится. Да, но, все-таки, в самом слове «предпринимательство» – там тоже заложен смысл – когда ты сам делаешь что-то.

• Во-первых, на что вы можете теоретически рассчитывать – господдержка 500 тысяч. Причем они жалуются, что у них нет заявок.

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

• Дальше – Сколково предлагает один миллион рублей.

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

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

• Ну и, конечно же, вас ждут сомнения, решения и успех.

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

Подходы к управлению проектной организацией Сергей Лебедев Директор компании ITLand (itland.ru), Координатор по развитию направления «1С:Решения для управления проектами»

От ведущего: Сейчас будет выступать представитель компании ITLand. 10 лет назад я очень многому учился именно у них на сайте. Мир вообще квадратный… А поскольку конференция у нас управленческая, мы знаем, что есть процесс разработки. И есть люди высокоуровневые, которые строят процесс. В SCRUM-е у Асхата Уразбаева это называется SCRUM над SCRUMом. То есть, если есть процесс SCRUM, то есть процесс SCRUM для тех людей, которые организуют процесс SCRUM. Верхнеуровневая такая кибернетика. То есть это процесс для тех, кто строит процесс. Сергей, я не ошибся, описывая тему твоего доклада?

От докладчика: Я немного уточню. У нас в компании есть такое понятие – проектно-процессный дуализм. Как раз когда все вечером в пятницу решают что-нибудь пообсуждать и начинаются споры на тему: что важнее – проекты или процессы, когда проект превращается в процесс и обратно. Компании могут выполнять процессы (обслуживание, например), компании могут выполнять проекты, а сам этот бизнес, если расценивать, что его кто-то открывает и через три года продает, это – бизнес-проект верхнего уровня. Кратко о компании ITLand:

Наша специализация – это разработка и запуск комплексных систем для проектно-ориентированных организаций. У нас совместно с 1С разработано три основных программных продукта. Мы, собственно говоря, ими и занимаемся – разрабатываем, внедряем, запускаем, работаем с партнерами.

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

Что еще хотелось бы сказать важного о нашей компании.

Корпоративный вид спорта в нашей компании – это дайвинг. Наши ребята давно этим увлекаются, занимаются. Я тоже это немножко проповедую. Ездим, ныряем.

– 125 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Ну а на одном из корпоративов мы доставали ядра с затопленного парусника «Портсмут» – это парусник из фрегата Петра Первого. Потом нам одно из ядер подарили и сделали на нем гравировку. Оно у нас в офисе хранится.

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

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

Основные понятия – проектный треугольник и портфель проектов

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

Еще – подледный хоккей. Это тоже придуманный нами вид спорта. Я думаю, мы сделаем маленькое видео и выложим его на сайт. Если кому-нибудь будет интересно, можно будет его посмотреть.

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

– 126 –

Сергей Лебедев

Подходы к управлению проектной организацией

Проектный офис Для управления портфелем проектов в компании появляется структура или подразделение, которое у всех по-разному называется: • Проектный отдел • Проектный офис

• Офис управления проектами • И пр.

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

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

• Либо проектный офис занимается прямым управлением проектом (распределением ресурсов, контролем, мониторингом, изменением, отвечает за достижение проектом определенных показателей). Обычно проектные офисы не отвечают за наполнение проектов и ресурсов (наймом сотрудников и принятием решений по открытию проекта занимаются другие люди).

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

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

Рассмотрим разные аспекты зоны внимания руководителя проектной организации.

Проектная организация По организации – то, о чем мы в начале говорили. Организации делятся принципиально на два типа по основному виду деятельности: • Проектно-ориентированные организации

• Непроектно-ориентированные организации

Если основной вид деятельности – это проекты, то, соответственно, такие компании относятся к проектно-ориентированным.

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

– 127 –

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

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • Следующий важный аспект проектной организации – персонал. «Кадры решают все!» А в трудоемком производстве это вообще самое основное, самое золотое.

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

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

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

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

• Кроме этого с ростом компании, большую важность в проектной организации получает аспект «Технологии и Знания», как они накапливаются в компании, как они передаются.

• И еще один аспект – «Взаимоотношения». Это могут быть взаимоотношения внутри организации или взаимоотношения с заказчиками, с подрядчиками.

• И, как результат всего этого, – общая экономика проектной организации.

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

Выводы:

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

• И это позволит делать работу для заказчика дешевле.

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

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

Стабилизация проектной системы – важнейшая задача

Можно ли достигнуть гармонии при работе с портфелем проектов? Или приходится мириться с тем, что люди постоянно работают в состоянии агонии, безостановочно «туша пожары»?

Первый пример – есть компания, «села» на крупного заказчика и работает. Вроде все прекрасно, но есть нюансы:

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

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

– 128 –

Сергей Лебедев

Подходы к управлению проектной организацией

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

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

Третий пример – проектов много, но на одном-двух проектах начинается завал. Начинают эти проекты «вытягивать», наваливают туда ресурсы, ресурсы «выдергивают» из других проектов. Обычные следствия: • Валятся эти проекты и другие проекты тоже.

• Ресурсы тратятся, деньги тратятся.

• Более того, возникает ситуация, что «проели авансы», в том числе с новых проектов. В общем, выстраивается «пирамида долгов». Вывод тот же – можно погибнуть.

Следующий пример – неоправданно быстрый рост компании. Компания растет быстрее рынка, както так получилось. Какая есть в этом случае у компании возможность? Собрать с рынка готовые ресурсы, причем задорого. Потому что это надо сделать быстро, и варианты – перекупать. Что получается: люди приходят, но эти люди – не приверженцы компании. Более того, стоимость подобных людских ресурсов может быть сильно завышена. Таким образом, отдачи по проектам может не получиться, а любое колебание может привести к тому, что народ разбежится. И, как следствие, высокие риски потери управления. С этим в реальности столкнулись несколько известных нам компаний.

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

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

– 129 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Это были такие страшилки-пугалки, которые, в общем-то, являются реальным набором историй с рынка за последние восемь лет. Кто-то может какие-то организации узнать.

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

Задачи проектного офиса В своей регулярной работе проектный офис решает две важных задачи: • Синхронизация • Ритм работы

Первое – это вопрос организационной составляющей.

Роль организационной составляющей

1. Первое – это правильное выполнение каждого проекта. Существуют даже специальные стандарты PMBoK, которые говорят о том, как правильно выполнять проект: —— Где «подстелить соломку» —— Где отработать то, то и то

—— Какие сделать документы —— И т.д.

2. Второе – выбор правильного набора проектов.

—— Не так давно в PMI появились стандарты управления портфелями проектов,

—— В России в прошлом году появились стандарты по управлению проектами, управлению портфелями и программами проектов. Небольшие, но появились уже. Большой шаг вперед – это хорошо.

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

3. Третье – это создание среды для успеха проектов. Это значит, что если эта компания работает на проектном рынке и занимается проектами, то в компании должна культивироваться проектная атмосфера. Там должны быть: —— Работа с персоналом, обучение, структура поддержки, наставничество и т.д. и т.п.

—— Должны нарабатываться технологии, собираться базы знаний.

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

По синхронизации – поясню, какой смысл вкладывается в это слово.

Особенности мультипроектного управления

Если мы говорим об одном проекте – то:

• У него есть рамки, время, бюджет.

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

• Проект состоит из набора процессов, которые выполняются.

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

А когда мы переходим к портфелю проектов – к мультипроектному управлению – то это:

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

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

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

– 130 –

Сергей Лебедев

Подходы к управлению проектной организацией

• Главное – цели проекта должны быть синхронизированы со стратегическим управлением в компании.

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

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

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

Также важной составляющей деятельности проектного офиса является так называемая «Внутренняя среда» – инфраструктура проектов, ресурсы, взаимоотношения между ними и так далее. Здесь проектный офис регулирует, как им надо интегрироваться, балансировать с процессами организации и т.д.

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

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

• Первое – это требования, ожидания. Инвесторы, директора эти требования/ожидания формулируют • Дальше – это возможности, угрозы рынка, какие-то идеи

• И, естественно, накачка стратегическими инвестициями.

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

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

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

Задачи проектного офиса при реализации проектов. Синхронизация портфеля проектов с производственными мощностями

• При управлении деятельностью очень важно понимать, какие у портфеля проектов есть ограничения

– 131 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 • В соответствии с этим надо думать, как должны быть распределены производственные мощности

• И, исходя из этого соотношения, принимать решения.

—— Во-первых, надо балансировать. Может быть, у нас проектов больше, чем мощностей. Может быть, наоборот. И это – большие, решающие проблемы.

—— Кроме балансировки, есть более существенные вещи, которыми тоже должны заниматься организации. Это такие вещи, как отказ от неправильных проектов. То есть те проекты, которые не вписываются в структуру, не согласуются с целями – с ними надо что-то делать. Лучше даже закрывать, невзирая на то, что туда уже вложено большое количество ресурсов, финансов, ну и просто жалко.

—— Дальше – обеспечение эффективности производственных ресурсов. Здесь можно привести пример, что ключевые специалисты по очень узким областям (уникальные в своем роде), например, архитекторы систем или функциональные архитекторы, не должны делать все рутинные операции, а желательно выделять их на ключевые точки постановки задачи и контроля над правильностью выполнения. А младшему персоналу передавать непосредственное выполнение работ.

Задачи проектного офиса при реализации проектов. Обеспечение ритмичности Дальше по ритмичности. Ритмичность – это борьба с инертностью. Очень часто бывает, что проект идет-идет-идет, а потом он «засыпает». Может быть, у заказчика что-то случилось, еще что-то и остается только какое-то вялое движение.

Поэтому ритмичность – вещь важная. Это вопрос регулярного продвижения вперед.

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

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

Обеспечение ритмичности. Как это делается на практике? Задается некий ритм каждого проекта, то есть:

• регулярные проектные статусы – статусы могут быть внутренние

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

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

– 132 –

Сергей Лебедев

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

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

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

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

• Со стороны заказов:

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

Рекомендации для стабилизации системы при проблемах с заказами Первый вариант:

• Ситуация

—— Первое – системный или надсистемный кризис приводит к отсутствию заказов

—— Изменения на рынке заказчиков. Простой пример – кризис. Кризис пришел – все, бу-бух!

—— Либо второе – высококонкурентный рынок с узкой воронкой продаж, слабыми технологиями продаж приводит к непонятному проценту «выстрела заказов». То есть, мы не можем понять, какой у нас будет портфель по заказам в ближайшее время.

—— Неопределенность спроса. Что-то изменяется, происходит. Неясность.

• Со стороны проекта:

—— Изменение ситуации у заказчика. Крайний случай – у заказчика меняется руководство или собственники. Как следствие, рестарт на всех проектах этого заказчика

—— Изменение параметров проектов. В нашей предметной области – это заказчик говорит: «Не, ну как же, у системы еще надо чтобы вот это тоже работало. Это тоже должно быть в рамках проекта». Или, например, дедлайн по срокам сдвигается (приближается). Или изменяются сами процессы у заказчика, может быть, параметры взаимодействия этих процессов («однако за время пути собачка могла подрасти»)

• Со стороны внутренней работы

—— Взросление персонала. Такое всегда происходит. Люди набираются опыта, знаний, навыков

—— Изменения в самой компании. Компания может переходить из стадии «Детство» в стадию «Зрелость» – и так далее по циклу Адизеса, по

• Рекомендации

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

• Следствие

—— Это позволит организовать поток обращений, соответствующий деятельности компании, даст возможность компании выбирать «правильные» проекты и работать «на потоке». То есть, компания сможет нормально существовать.

Второй вариант:

• Ситуация

– 133 –

—— Несфокусированный портфель заказов. Заказы не соответствуют тематике и технологиям. Взяли с рынка все что есть, пытаемся делать, но структура компании, люди и их ком-

INFOSTART JOURNAL №2 НОЯБРЬ 2013 петенции не соответствуют принятым заказам. Ситуация напоминает «тушение пожаров»

• Рекомендации

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

• Следствие

—— Отказ от «неправильных» проектов высвобождает ресурсы.

Третий вариант:

• Ситуация:

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

• Рекомендации

—— Балансировка планов, заказов и мощностей

Рекомендации для стабилизации системы при проблемах с портфелем проектов и ресурсов Первый вариант:

• Ситуация

—— Не хватает «выстреливших» заказов, которые перешли в конкретные договоры. Ресурсы недозагружены.

• Рекомендации

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

• Следствие

—— Минимизация простоев —— Минимизация затрат

Второй вариант (ситуация обратная тому, что было в первом варианте): • Ситуация

—— Портфель проектов не обеспечен ресурсами —— Несоответствие компетенций

—— Работы со свободной датой окончания

—— Нет кадровых резервов

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

—— Объем сверхрисковых проектов>20% от всего портфеля —— Нет временных резервов в проектах —— Не выстроена соответствующая структура команды

• Следствие

—— Гармонизация плановой загрузки

—— Слабая «тасуемость колод» проектов и персонала (нет возможности перекидывать людей с проекта на проект)

Четвертый вариант

• Ситуация:

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

—— Oversale. Набрали заказов на порядок больше, чем можно выполнить.

• Рекомендации

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

проектам

• Рекомендации

—— Типизировать проекты

—— Структурировать проектные команды

—— Выстраивать однотипные проекты в очередь, ходить по этим проектам одной командой

• Следствие

—— Накапливать и повторно применять знания

—— «не порвешься».

—— По каждому действию получать несколько результатов: один «выстрел» (один проект) – два результата —— Планировать резервы

• Следствие

—— Соблюдение сроков проектов портфеля

Третий вариант

• Ситуация

– 134 –

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

Сергей Лебедев

Подходы к управлению проектной организацией

• Рекомендации

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

• Следствие

—— Возможность выбора

Четвертый вариант:

Рекомендации для стабилизации системы при проблемах с финансами Первый вариант

• Ситуация

—— Получение большого процента низкооплачиваемых или высокорискованных заказов в общем портфеле проектов приводит к низкой или отрицательной рентабельности проектов

• Рекомендации

—— Ситуация

—— Перегруз специалистов

—— Уход специалистов на «зеленую лужайку» – это частая история во всех видах бизнеса, когда человек просто заработался, сгорел, устал, хочет отдохнуть. Работать на окладе, получать фиксированные цифры. Это обычная история. Это данность

—— Уход экспертов, желающих «свободу творчества при максимальном окладе» —— «Корона» у специалистов. Люди после прохождения проектов не желают браться за рутинную работу —— Долгая подготовка специалистов и руководителей проектов

—— Это все обычные кадровые проблемы, которые существовали и 50 лет назад, и будут существовать и дальше, во всех странах и везде.

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

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

• Следствие

—— Управляемая рентабельность

Второй вариант

• Ситуация

—— Нетехнологичность, которая вызывает низкую рентабельность проектной деятельности

• Рекомендации

—— Технологии надо нарабатывать

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

• Рекомендации

—— Обеспечение возможности карьеры и профессионального роста

—— Соблюдение принципа, который часто применяется в консалтинговых компаниях, «вверх или в сторону»

• Следствие

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

• Следствие

—— Управляемая рентабельность

Третий вариант

• Ситуация

—— Неравномерность и задержка платежей привела к кассовым разрывам в финансовом состоянии организации

• Рекомендации

—— Резервы или возможность короткого кредитования

—— Перекрытие разрывов потоком по стабильным видам деятельности

• Следствие

—— Закрытие кассовых разрывов

Четвертый вариант

• Ситуация

—— Завал проектов приводит к отрицательной рентабельности деятельности

• Рекомендации

—— Уменьшать процент высокорискованных проектов

– 135 –

—— Выходить из проекта, если совсем плохо

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Заказы не соответствуют профилю компании, соответственно, нет сфокусированного накопления клиентского актива

• Следствие

—— Положительная рентабельность

Пятый вариант

• Ситуация

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

• Рекомендации

—— Управление рентабельностью каждого проекта —— Управление денежным потоком

• Следствие

—— Положительная рентабельность.

• Рекомендации

—— Либо специализироваться на конкретике

—— Либо увеличивать масштаб и «всеядность» организации

• Следствие

—— Конкурентные преимущества либо по модели «фермеров», либо по модели «охотников»

Второй вариант:

• Ситуация

—— Нет общей, объединяющей идеи, лидера. Разобщенность команды

• Рекомендации

—— Объединяющая идея, личность —— Воля к победе

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

• Следствие

—— Организационная общность, стиль и согласие

Рекомендации для стабилизации системы при проблемах со стратегией Первый вариант:

• Ситуация

– 136 –

Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде Артур Абеленцев Руководитель проектов, заместитель генерального директора ООО «АРТ саТерра»

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

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

Нормативная база

Давайте с нормативной базы начнем.

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

Личный опыт

Соответственно, за период 2012-2013 года – шесть исков на общую сумму чуть больше 13 миллионов рублей. Вся статистика перед вами.

По нашей деятельности, наши договоры между юр. лицами регулируются Гражданским кодексом.

Как только мы идем в суд – надо начинать читать Арбитражный процессуальный кодекс. Что надо прочитать в Гражданском кодексе?

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

Выполнение этапа

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

Теперь к делу. Классика жанра – на этом слайде изображено, как выполняется этап по шкале времени.

– 137 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Дальше – на этапе приемки заказчик отказывается от приемки. Отказы бывают мотивированные и немотивированные.

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

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

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

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

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

Техника безопасности (в тексте договора)

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

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

Проблемы в ходе выполнения этапа

Соответственно, какие проблемы у нас могут возникать?

• Начнем по риску отказа от оплаты аванса.

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

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

– 138 –

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

Артур Абеленцев

Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде

Техника безопасности по отказу от приемки и по отказу от договора (в тексте договора)

чае с авансами) или счета-фактуры (оплата по подписанным актам).

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

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

• Следующий набор проблем – это все, что в ходе выполнения возникает. Как с такими проблемами бороться? Четкие формулировки в договоре, чего вы хотите от Заказчика.

Отдельно вынес два самых тяжелых случая.

• Первый из них – отказ от договора. Мы потом отдельно еще на нем остановимся. Что я в практике подсмотрел?

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

—— Если вам нужен удаленный доступ, вы привыкли с ним работать, то пишите это в договор, чтобы потом с удивлением не обнаруживать, что заказчик говорит вам – «Ходите, пожалуйста, ко мне в офис. Я знать ничего не знаю об удаленном доступе».

—— Что касается предоставления информации – опять же, не советую ограничиваться какими-то общими формулировками, наподобие «Заказчик предоставляет всю необходимую информацию». Вот вам, допустим, на этапе обучения нужна одна какая-то информация от заказчика или доступ к каким-то ресурсам, а на этапе переноса остатков – совсем другое. Где вы в договоре этапы формулируете, там же крайне полезно по каждому этапу хотя бы в общем виде обозначить, что вы будете от заказчика ждать.

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

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

• Тяжелый случай – отказ от приемки. Что на этапе подписания договора необходимо предусматривать?

• Отказ от оплаты принятых услуг.

—— опять же – выкидываем из договора слова про счет

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

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

– 139 –

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

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Второй важный момент – результаты ваших услуг должны быть в пределах вашего контроля. Мы сейчас в конкурсе одном участвуем. Там Заказчик в проекте договора, в конкурсной документации написал, что исполнитель должен обеспечить заказчику 20% сокращение персонала по результатам реализации системы. Но дело в том, что сокращение персонала не находится в вашей власти. Заказчик захотел – уволил. А не захотел – не уволил. Вы не получили свои деньги. Надо переформулировать такое утверждение. Допустим: «Разработанные регламенты процессной модели «как будет» должны предусматривать плановое сокращение на 20% по сравнению с моделью «как есть»». Вот это уже в вашей власти. Вы можете это в модели обеспечить.

• Далее – Исчерпывающий перечень документации. В договор надо вписать – по завершении каждого этапа мы сдаем:

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

• Сроки предъявления мотивированного отказа. Как ситуация видится со стороны заказчика? Принес исполнитель «макулатуру». Положил ее и говорит – «проверь и подпиши акт». Сотрудник заказчика может три месяца смотреть или не смотреть эту документацию – зарплату он все равно получает. И он, в этом смысле, достаточно комфортно себя чувствует. А у вас ситуация другая: нет подписанного акта – нет денег. Нет денег – нет возможности выплатить зарплату своим сотрудникам. Некоторые сотрудники заказчиков ведут себя как летчики гражданских самолетов, которым вдруг парашюты выдали. Они думают: «Если что-нибудь сломается, я выпрыгну, и все будет хорошо». Парашютов их надо лишать, потому что иначе вы не будете достигать цели проекта.

Техника безопасности в ходе выполнения

—— акт (2 экземпляра);

—— счет-фактуру (кому полагается);

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

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

• Крайне важный момент – определить порядок передачи! Если вы приходите и просто кладете заказчику на стол материалы – считайте, что передача у вас не состоялась. Вариантов два: —— Надежный, но долгий. Почта России, заказное письмо с уведомлением и описью вложения;

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

Два последних пункта очень важных:

• Мотивированный отказ. Когда я изучал договоры коллег, то у всех в договорах есть слова про мотивированный отказ. Но только в двух договорах я встретил четкое определение того, что такое «мотивированный отказ». Например, вы внедряете бухучет, а у заказчика что-то в бизнесе поменялось. Соответственно, на момент сдачи заказчик вам говорит: «А мне сейчас уже так не нужно, мне уже сейчас по-другому нужно». Это мотивированный отказ, по-вашему, или нет? Соответственно, в договор лучше прописать, что мотивированный отказ – это обнаруженное явное несоответствие

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

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

• Второе: как только вы начинаете испытывать более-менее серьезные затруднения в работе – это не повод для скандала, но это повод создать материальный след того, что вы эту проблему обнаружили и заказчика о ней проинформировали. Вот здесь можно смело «Почту России» использовать. Допустим, есть у вас этап переноса остатков.

– 140 –

Артур Абеленцев

Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде

Сделали вовремя – успели запуститься в январе. Не сделали – не успели. Важный момент? Важный. Заказчик тянет с предоставлением исходной базы для переноса. Поставьте его в известность о том, что он вообще срывает весь проект из-за того, что тянет с базой. Причем поставьте его в известность об этом через Почту России.

Какие точки фиксируем:

• начало этапа, • конец этапа,

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

на руках уже должно быть подготовленное исковое заявление. Если срок, обозначенный в претензии, прошел, отправляете иск стороне и в суд. Стесняться никого не надо. К примеру, заказчик в этот момент исправляется и выполняет свои обязательства – вы всегда можете иск отозвать, не обязательно нужно до конца идти. Но! Здесь есть важный момент: не реагируйте на обещания «Ты иск отзови, а мы через два дня исправимся», потому что, если вы иск отозвали, то повторно по этому же поводу в суд обратиться не имеете права, вообще никогда нигде на территории Российской Федерации. Дождались выполнения исковых требований – отозвали иск, по-другому нельзя. Вероятность проигрыша не рассматриваем, исходим из того, что мы добросовестно исполняем обязательства по договору и соблюдаем технику безопасности.

Не удалось договориться. Последовательность действий Соблюдаем технику безопасности. Что-то пошло не так, не удалось договориться. Запускаем досудебный порядок.

Поход в суд. Когда мы будем ходить в суд?

• Либо нас вызвали и мы ответчик.

• Либо мы туда сами идем и мы истец

• (есть еще вариант, когда мы третья сторона, например – назначенный судом эксперт. Но это уже за рамками нашей беседы) Досудебный порядок – это письмо, в котором написано о претензиях в порядке до арбитражного регулирования. В этом письме вы заказчику сообщаете, что «В соответствии с договором (или в соответствии с приложением к договору), пункт такой-то, вы должны были сделать это и это – вы не сделали (или вы не заплатили). Прошу в срок до такого-то числа устранить допущенные нарушения. В противном случае мы будем вынуждены обратиться в суд».

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

По-хорошему, когда вы готовите претензию, у вас

Лучше быть истцом. Почему?

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

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

– 141 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Доказательства и доказывание

Нет ущерба имиджу.

Давайте про доказательства.

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

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

У одного из наших заказчиков начались проблемы с руководством – раз в полгода там меняется генеральный директор, и, в связи с этим, проект уже железобетонно остановлен. Мы очередной этап завершили в апреле 2011 года. То есть, фактически, услуги оказаны, но, из-за многократной смены руководителя, документы не подписаны. В апреле 2012 года (год прошел) я вспоминаю о том, что этап завершен и неплохо было бы получить от заказчика стоимость этого этапа. Как я сам в технике безопасности писал – Почтой России, передаточное письмо, акты, результаты оказанных услуг. Ничего не дождались, мотивированного отказа нам никто не предоставил (они просто проигнорировали передаточное письмо), в конце года выходим в суд. С судьей начинаем ситуацию обсуждать, и я судье говорю – «Вы знаете, у нас год назад отключили терминальный доступ, мы целый год не могли работать, и вот, только через год сдали этап». Судья: «Так, интересно… У вас, значит, не было возможности услуги оказывать, а вы тут какие-то результаты сдаете?» Тут я понял, что я что-то лишнее сказал. С тех пор я в суд не хожу и вам не советую.

Плохие доказательства.

• Свидетельские показания. Есть такая иллюзия почему-то у многих, что сейчас мы вызовем 100 свидетелей и они в суде расскажут, какие мы прикольные, что мы все закончили, и судья радостно крикнет: «Дорогой ты мой, конечно же, ты прав! Сейчас мы тут всех накажем». Ничего подобного. За шесть исков нам не удовлетворили ни одного ходатайства о вызове свидетелей. Причем, вызывали мы не своих сотрудников, мы вызывали сотрудников противной стороны. Несмотря на это судья сказала «Мне не интересно, что люди рассказывают. Все врут»

• Далее – Экспертиза по собственной инициативе. Был смешной случай в последнем деле. Когда ответчик привлек другого франчайзи и другой франчайзи пришел и сказал «Конечно, это нехорошие люди, они вас обманывают. Все не так, реализация задачи неправильная». Тут судья так обрадовалась «А, я поняла, вы хотите заплатить за экспертизу! А то вы приносите какие-то доказательства, а я же не поручала никому ничего делать. Вот, сейчас поручу, а вы заплатите». Я к чему это веду. Не надо ничего такого объяснительного приносить от третьей стороны, пока судья не поручит. То есть, пока нет поручения судьи, ее не интересует, что там говорит третья сторона • Распечатки электронной почты. Что такое электронная почта, если нет ЭЦП? Вы ни время, ни содержимое не можете подтвердить.

• Еще момент – «У нас есть Устав проекта, а заказчик не выполняет его условия. Там указано распределение рисков, и этот риск распределяется на заказчика». А представитель заказчика говорит – «А что, устав – это приложение к договору?» Если оказывается, что нет, то судья это отбрасывает. То есть, все, что не является приложением к договору (то есть, в договоре об этом не написано), не рассматривается в рамках дела.

– 142 –

Артур Абеленцев

Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде

Хорошие доказательства • Самое лучшее – бумаги подписанные уполномоченными лицами обоих сторон. Причем тут важно каждое слово —— Бумаги – то есть, это не электронный вид,

—— подписанные – то есть, это не ваша распечатка, оставленная на столе у заказчика, как результат совещания, —— уполномоченными лицами – не абы кем, а –

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

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

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

Экспертиза. Вопросы эксперту

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

• «Обеспечивает ли выбранный Исполнителем способ обращения к веб-сервису выполнение второго правила нормализации базы данных?» К примеру, эксперт выносит решение «Не обеспечивает». Судья читает и говорит «И что???» А может, он и не должен обеспечивать? А может, это вообще очень хорошо, что он этого не обеспечивает, понимаете? То есть, судья по ответам на такие вопросы не может сделать вывод о том, насколько услуги оказаны в соответствии с требованиями договора. Правильные вопросы на слайде тоже показаны:

• Самый главный вопрос «Предусмотрены ли требования Заказчика условиями договора?» – сразу отбросили фантазии о том, что заказчик сам себе придумал.

• Второй вопрос: «Обнаруженные недостатки: значимость (существенность), возможность устранения, затраты на устранение». Почему важно? В любой работе можно найти недостатки, но одно дело, когда вы построили домик и в него заходить даже опасно. А другое дело, если вы дом построили, зайти можно, но в туалете одна плитка кафеля отвалилась. То есть, домом можно пользоваться. В таком случае, судья может выносить решение о том, что вам там не 100 рублей положено, а 99, например. По крайней мере, вы не теряете всего.

• Далее – «Возникли ли отклонения/недостатки по вине Заказчика?» Внедряете бухучет, первый квартал прошел, опытная эксплуатация закончилась. Формируете отчетность. Баланс не сходится. Заказчик пишет отказ от принятия – как это так, баланс не сходится, что это за система бухучета? А эксперт изучает исходные данные, которые были предоставлены для переноса. Обнаруживается, что у заказчика баланс уже лет пять, как не сходится. То есть, ему нет повода сходиться, и вашей вины в этом нет.

Обеспечение доказательств

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

Неграмотные стороны формулируют вот такие вопросы, как показаны на слайде:

Практику обеспечения доказательств мы подсмотрели у Microsoft.

– 143 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Компенсация понесенных затрат

Какая там была ситуация у Microsoft? Представители Microsoft обнаружили, что в какой-то школе используется нелицензионная Windows. По этому поводу Microsoft пишет письмо в школу: «Купите, все-таки, лицензионную Windows!». Директор школы пишет в ответ: «Ребята, не могу – денег нет».

Microsoft обращается в суд с иском. Директор школы получает по почте этот иск и определение. В школе тут же дается команда стереть Windows, поставить Linux. И Microsoft в суде уже не сможет доказать, что школа чего-то нарушила в части использования ПО. В АПК есть отдельная статья, которая так и называется «Обеспечение доказательств». Эта статья о том, что если одна из сторон видит доказательство, которое находится в ведении другой стороны и есть риск уничтожения или устранения этого доказательства, то эта сторона может обратиться к суду с ходатайством о том, чтобы суд выпустил отдельный исполнительный лист – поручение об обеспечении доказательств. И тогда вы с приставами пойдете на территорию заказчика, и там пристав (с привлечением соответствующих специалистов) сделает то, что написано в исполнительном листе, – скопирует БД, снимет логи подключений, и т.п.

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

• У вас остается свидетельство людей, которые видели, как вы ходили – оно не считается • У вас остается копия базы данных – она тоже не считается

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

Помните, про расторжение договора в самом начале мы говорили, что это очень плохо. Почему плохо? Потому что в этом случае получить что-либо в качестве компенсации понесенных затрат будет крайне непросто. Рассматриваем вариант, когда договор расторгнут по инициативе заказчика (не в связи с нарушениями условий договора с вашей стороны). ГК при расторжении договора по инициативе заказчика (например, в связи с утратой интереса) предусматривает компенсацию исполнителю фактически понесенных затрат. Но, чтобы эту компенсацию получать – необходимо доказать объем фактически понесенных затрат. Что такое фактически понесенные затраты в нашей деятельности? Это немножечко прямых затрат и большая доля накладных затрат. Какие вопросы возникнут у судьи, и будут поддержаны противоположной стороной?

• Зарплату сотрудников в качестве понесенных затрат выставили. А как вы докажете, что Иванов все свое время (все свои 90 тысяч в месяц) тратил на то, чтобы работать именно в этом проекте? А если Иванов, к тому же, начальник отдела, то все понимают, что Иванов еще чем-то занимался. Значит, не 90 тысяч. А сколько? Нельзя объективно определить. А если нельзя определить, значит, ноль. Понимаете юмор ситуации?

• Накладные расходы. Почему такая доля? Почему такая база разнесения? Почему такой способ разнесения?

• Субподрядчики. Если это договор оказания услуг, предусмотрено ли договором привлечение субподрядчиков? Имели ли вы право делать это без согласования с Заказчиком?

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

– 144 –

Артур Абеленцев

Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде

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

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

Выиграли. Что дальше?

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

Исполнительный лист – это такая команда специально обученным людям сделать то, что в исполнительном листе написано. Если в исполнительном листе написано, что вам нужно вернуть деньги, то у вас есть два варианта: • Вы идете в банк должника. Это быстро.

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

• Сейчас крупные компании спрашивают в конкурсной документации «были ли вы ответчиком? Почему? Чем закончилось?». Обратите внимание, их не интересует, были ли вы истцом.

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

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

Теория – структура судебной власти в РФ

Немножко теории – структура судебной власти. У нас есть такие суды:

Ну и, соответственно, если выиграли, имеете право на компенсацию затрат на услуги привлеченного юриста (если юрист наемный – не в штате).

Имиджевые последствия

Когда спорят юридические лица – они «клиенты» арбитражных судов. Появился специальный суд по интеллектуальным правам. Мы, наверное, в нашей работе его не сильно касаемся. А вот Microsoft, разработчики софта – они будут туда ходить в случае чего.

Есть еще третейский суд, но это экзотика. Причем, экзотика дорогая. Туда ходить не надо.

– 145 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

Арбитражный суд – самый автоматизированный

Опыт коллег.

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

Абсолютно все дела, которые не под грифом «Секретно» – вы можете здесь прочитать.

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

Заходим на сайт kad.arbitr.ru. В участники дела забиваем интересующие нас названия (примеры на слайде). Нажимаем кнопку «Найти».

Самое полезное там – полные решения. Судья объясняет, почему он это доказательство принял, а это нет. Это очень полезная вещь, читайте на ночь, вместо сериалов J

– 146 –

Организация жесткого контроля при внедрении информационных систем Алексей Патюков

Консультант по постановке и организации учета. Ведущий рубрики «ФРИЛАНС: Инструкция по применению»

От ведущего: Алексей, объясни, жесткий контроль – это как? Прямо ногами? От докладчика: Прострелить коленку, в первую очередь. А по-хорошему, то, что я понимаю под термином «жесткий контроль» – это тотальная слежка за работой пользователей на провальных объектах учета. Зачем? Первый момент – я не внедренческая фирма. Я – фрилансер. Если я проект не закрою и денег не получу за три-четыре месяца работы на этом проекте, то прибыль за год у меня выходит в ноль. Соответственно, моя задача – процесс внедрения организовать так, чтобы при запуске у меня не было сбоев. Я стараюсь перед началом запуска убрать все факторы риска. Соответственно, я провожу анализ. Работаю с владельцами бизнеса. Ставлю на заметку провальные зоны доступа в компании. И эти зоны ставлю на тотальный контроль. Внедряю наблюдателей на проекте, которые там с секундомером работают. И внедряю администраторов. Основная задача – убрать все риски и по факту проекта получить деньги. Я – фрилансер. На своих проектах финансовый вопрос я обязан полностью закрывать сам. Работаю с компаниями, в которых до 50 рабочих мест. Как правило, это спокойный управляемый проект на одного человека. По обороту – у контор, с которыми я работаю, годовой оборот бывает до 2-х миллиардов.

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

Основные блоки доклада Их четыре:

• Экспресс-анализ и диагностика компании • Работа с дирекцией и владельцами бизнеса

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

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

Первый этап. Экспресс-анализ (диагностика)

• Работа с сотрудниками • Запуск системы

На этом этапе я попадаю в компанию, и я ничего о ней не знаю.

– 147 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 —— Второй вариант – моя экспертная оценка. Разница в экспертной оценке – это тоже серьезный показатель. Иногда она достигает 20-30 раз. Когда у меня норматив на ввод документа – 1 минута, а у представителей компании – 30 минут, я понимаю, что на данном блоке учета надо еще поставить третью галочку. Соответственно, здесь у меня будут максимальные риски. Потому что, если пользователи достаточно ленивы, их придется подталкивать, «бить дубинкой» и применять другие способы воздействия (также эмоциональный способ).

Мои задачи:

• Собрать сведения об общем отражаемом документообороте в системе. В семерке это Базопузомер. В восьмерке – свои средства. Если работаете – знаете. Собираем все эти сведения. Группируем по видам документов. Группируем по блокам учета.

• Оценить временной лаг ввода документов. Что это такое? Оценивается расхождение по времени между попаданием документа в компанию, допустим, на физическом носителе (бумаге), и размещением его в информационной системе. Это один из самых жестких показателей. А как его измерить? По логам. И в семерке, и в восьмерке они отражаются. Простейший пример: когда я вижу, что у меня документ отражен 23 февраля, но по логам дата, допустим, 9 мая – я сразу высчитываю, что лаг расхождения почти три месяца. Как вы думаете, при таком способе ввода информации насколько корректна отчетность? Соответственно – я вижу блок учета, где лаг максимальный, и ставлю на карандаш. Если в бухгалтерию документы с такой задержкой приходят – это проблемы бухгалтерии, что она не может организовать нормальный документооборот с организациями-контрагентами поставщиков. Это все равно лаг, и лаг бухгалтерии, а не лаг ввода документов. Но это все равно лаг и его надо оценивать. Лаг оценили, галочку поставили на всех объектах учета, где он превышает допустимые параметры. В компаниях, в штате которых я раньше работал, сроком предоставления управленческой отчетности был второй день месяца. Соответственно, допустимый лаг по вводу документов – два дня максимум. Сейчас, когда я прихожу в компанию и вижу лаг в три-четыре недели – мне внутренне становится смешно. Я понимаю, каких параметров можно достигать, понимаю, каким образом этих параметров можно достигать и это организовываю. Владельцы бизнеса, как правило, бывают очень довольны.

• Оценить временные затраты на ведение документооборота в 2-х вариантах.

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

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

• Проанализировать документооборот в разрезе организаций. Для чего? Зачастую, когда приходишь в компанию, там структура ведения документооборота организована не по функциональному признаку, а по юрлицам. Три главных бухгалтера ведут каждый по 40-50 документов в день. Всех устраивает. Общий документооборот – 150 документов в день. Для меня это – очень мало. На постоянной работе, где я работал раньше, нормальная нагрузка была – от 400 до 500 документов на оператора в день. Для меня бухгалтер – это точно такой же оператор. В плане ввода информации различий в моем восприятии нет никакой. Соответственно, недогруз по конкретной организации (юридическому лицу) тоже смотрим обязательно. Есть проблема недогруза – ставим себе на заметку. Плюс – еще следующий момент. Если они разделены по юридическим лицам, каждый пользователь создает документы по всем объектам учета. Очень много переключений внимания. Соответственно, замедление ввода документов, ошибки в результате переключения внимания и прочее. Соответственно, бонусная задача – добиться реструктуризации компании на функциональную систему обработки документов – не по юрлицам. Но это уже по воле владельца бизнеса.

• Проанализировать данные по регистрам учета

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

– 148 –

Алексей Патюков

Организация жесткого контроля при внедрении информационных систем

предоставить, которую сдавали владельцам бизнеса и директорату». Сравниваем. Видим расхождения, ставим на карандаш. Это – основной блок. Как правило, он занимает от одного дня до двух недель в зависимости от размеров организации. Если в компании бардак, как правило, главные бухгалтера не анализируют документы. Если я вижу неправильно сведенный баланс, если я вижу на 19 счете отрицательные остатки – это качество работы главного бухгалтера. Таких главных бухгалтеров надо увольнять. У меня есть такие полномочия. Сейчас я расскажу, как я их получаю.

• Собрать информацию о дополнительных затратах специалистов. Я это делаю не всегда. Почему? Бухгалтеры утверждают, что они очень много времени проводят за Консультантом, чтением методической литературы и пр. По факту, информацию об изменениях в законодательстве в 75% случаев они получают от специалистов 1С. А вы своих бухгалтеров бухгалтерскому учету не учите? Ну да, ну да… Соответственно, у них есть еще подготовка отчетности. Если учет выстроен, если ежедневно сверяются данные,то сдать отчетность – это дело одного дня. Не надо аврально работать, требовать премии за это. Иначе получается, что бухгалтера работают как студенты: «От сессии до сессии живут студенты весело…» Ни одной нормальной компании студенты не нужны. С контрагентами должны работать менеджеры по продажам, либо менеджеры по закупкам, либо специалисты по хозяйственной части – в зависимости от входящего или исходящего документооборота. В нормально отстроенной организационной системе бухгалтеры с контрагентами не работают. Моя задача – выстроить структуру документооборота так, чтобы владелец сказал, что «Ты знаешь, меня вот это устраивает больше, чем было раньше».

нормальной организации учета, то дальше у меня будет провал где-то в 75%. Я это точно знаю. Моя задача – сместить акцент получения информации о деятельности своей компании с внешних источников на информационную базу. Очень много приходится разговаривать с владельцами бизнеса. Почему? Разный уровень образования, разные причины создания бизнеса, разный уровень ответственности и прочее. Плюс – свои психологические причины. Люблю работать с военными – максимально конкретные люди. Период смещения внимания с внешних источников на внутренние занял у меня на одном проекте три года. Мы три года с директором общались. Я приходил к нему. Мы пили кофе, разговаривали о цветочках, облаках и т.д. Параллельно я его загружал информацией о том, какие виды отчетности бывают, для чего это требуется, какие показатели можно снимать. Три года он мне отвечал так: «Да, все классно, интересно, но… ты же меня понимаешь, Алексей?» «Да, я тебя понимаю. Дальше что будешь делать?» «Ну, пока вот так. У меня все хорошо». В этом варианте директор и владелец – это одно лицо было. А тут, буквально неделю назад у меня был разговор с ним и он мне: «Алексей, я через два года хочу создавать еще один бизнес. И туда хочу поставить наемного директора. Мне требуется полная прозрачность информации и контроль». Для меня это сразу сигнал – клиент мой. Дальше все становится очень просто, технологично и спокойно.

Работа с владельцами и с дирекцией компании

Продолжительность этой работы может занимать от одного месяца до трех лет. У меня были компании, в которых на время диагностики брался тайм-аут на 3 года. Расскажу причину. Организация сама работает «на всех парах». Производство загружено полностью. Деньги дает капитально, постоянно. Состояние бухгалтерской отчетности владельца не интересует. Все вопросы с налоговой решаются административным путем (есть всякие варианты решения, и если эти варианты работают, то смысл заморачиваться с бухгалтерским учетом). Плюс – он получает данные об успешности своей компании не из компании самой, а из внешних источников. Допустим, строительство – это саморегулируемые организации. Объем всех строек известен полностью. Соответственно, посчитать свою долю на рынке, ее увеличение или уменьшение – не проблема: две цифры сравнить. И вот тут начинаются проблемы, потому что если владелец бизнеса не заинтересован в

Обсуждаем временные затраты работы пользователей. Конкретно с владельцем. Все остальное он будет сам делать и достаточно успешно. То есть, если я договорился об акценте на систему–90% моей работы, как технолога, уже сделано. Дальше пойдут просто этапы – шаги, которые достаточно просто реализуются: • Обсуждение временных затрат сотрудников на ведение учета. Принятие решения о вводе нормирования работ сотрудников. Человек сам принимает решение, какой экспертной оценке верить. Либо верить своему главному бухгалтеру, либо верить мне. По необходимости я могу самостоятельно, в качестве оператора отработать весь блок учета. Если надо вбить 1000 документов в течение двух дней – пожалуйста, спокойно сажусь и

– 149 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 фаза – на владельце. Говорю еще раз, у меня владельцы бизнеса – это те, кто этот бизнес отстраивал сам. Поэтому этот момент мы отрабатываем с ними. Владелец сам скажет, какие блоки ему важны. Ему без разницы мнение пользователей (бухгалтеров, менеджеров отдела продаж). Он показывает те блоки, которые важны ему здесь и сейчас. Потому что бывают различные ситуационные вещи, которые пользователь просто не сможет рассказать. Владелец имеет информацию внутри организации и внешнюю.

вбиваю. Человек видит, что норматив достижим и, соответственно, свое решение принимает.

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

• Обсуждение кадровых перестановок, увольнения и найма персонала. Принятие решения об изменении штатного расписания. У 90% случаев проблемных клиентов вопрос звучит так: «Главного бухгалтера увольнять будем?» Просто стандартно. Допустим, в 2009 году у моих клиентов было четыре главных бухгалтера уволено. Это простой вопрос. Это вопрос технологичный. Если вы хотите успешно завершить проект, и потом ни с кем не судиться, а просто нормально пожать друг другу руки, здесь выход. Тотальная смена персонала по проблемным участкам. Сразу говорю, там, где есть финансовый директор, вопрос о ценности главного бухгалтера не стоит в принципе. Главные бухгалтеры в данных компаниях – расходный материал. Меняются просто щелчком пальцев. Мне тут говорят, что финансовый директор отвечает за финансовую часть, а главные бухгалтеры отвечают за регламентированный учет. Все согласны? Нет. В большинстве случаев это не так.

• Обсуждение ФОТ сотрудников на ведение учета. Принятие решения об изменении ФОТ. Возвращаю директора к первому своему пункту «Собрать сведения об общем отражаемом документообороте» и напротив каждого документа я показываю стоимость введения этого документа в рублях. Показываю ему калькулятор аудиторских бухгалтерских фирм, где есть норматив на введение этого же документа (сейчас очень много контор пользуются калькуляторами, чтобы привлекать себе бизнес). Так вот. У меня было забавное расхождение. Стоимость ведения учета с точки зрения аудиторов – 100 рублей за документ. По факту затрат только на ФОТ, без учета налогов, взносов и всего остального, на данном предприятии было 543 рубля 74 копейки. Представляете – вбили один документ – все, 540 рублей вам зарплаты капнуло. Знаете, я хочу работать на такой работе. 500 рублей за транзакцию, практически.

• Определение порядка внедрения блоков ИС. Назначение ответственных лиц. Завершающая

Ремарка: Основные задачи фрилансера

• Первое – получить с клиента деньги, потому что нужно все-таки кормить семью;

• Второе – запустить «сарафанное радио» с помощью клиента.

• Если я получаю «сарафанное радио» от владельца бизнеса, то от бухгалтера оно мне не нужно. Бухгалтер и владелец владеют разными финансовыми потоками. Бухгалтеры оперируют суммами в 10-20 тысяч рублей на расходы, а владелец принимает решения в принципе.

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

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

Как это бывает? Когда я ввожу экспертную оценку, владелец бизнеса говорит: «Ты молодец, ты хорошо все говоришь. Давай посмотрим, что скажут мои сотрудники». Как правило, приглашаются начальники подразделений, либо экспертные сотрудники в этом подразделении. Или, зачастую, сначала приглашается начальник, а потом эксперт. Так вот, уже здесь я уже могу прогнозировать с вероятностью 75% еще дополнительные риски по персоналу на внедрение проекта.

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

– 150 –

Алексей Патюков

Организация жесткого контроля при внедрении информационных систем

Запуск

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

Если кратко:

Итак, работа с сотрудниками.

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

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

• Нейтрализация «неприкасаемых». Ситуация какая: некоторых сотрудников нельзя уволить. В принципе. Есть, допустим, политические моменты, в которых они работают. На заводе (мясокомбинате) работал сын одного из «генералов», приятеля владельца бизнеса. То есть, сына этого надо было куда-то устроить. Его устроили начальником отдела администрирования системы. Квалификация ноль. Пинать его мне запретили: «У него там папа, а папа мне нужен, нужен очень сильно». Что делаем? В данном случае говорим: «Денис, поздравляем, у тебя повышение» и берем ему в подчинение сотрудника. Директор понимает, что это его организационные расходы на ведение бизнеса, которые позволяют ему бизнес вести и фиксирует ему зарплату: «Раз сын генерала, значит, минус 50 тысяч из бюджета ежемесячно». Он просто эту цифру зафиксировал и все. То есть, либо взятку давать, либо сына держать на работе. Взятку больше. Сына меньше.

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

• Ввод администратора информационной системы. Примерно в 80% проблемных предприятий такого понятия, как «администратор информационной системы» даже нет. Есть программист, который решает проблемы, а вот понятия «администратор информационной системы» нет. Но администратору можно платить 30 тысяч рублей, а программисту – 70. Администратором может быть достаточно опытный пользователь. Изначально я им предоставляю своего администратора системы, а потом эту функцию мы переводим в функционал предприятия. Его задача – контролировать работу системы и снижать количество ошибок.

• Контроль поступления первичной документации. Мы должны зафиксировать все информационные потоки и поставить их на карандаш.

• Обучение с вводом нормативов. Я требую, чтобы у пользователей была буквально физиологическая память. То есть, если документ вводится, то он вводится со строгим порядком, ни шага влево/ вправо на обдумывание, на принятие каких-то решений. Моторика достигается за 50-100 повторений ввода одного документа. Под секундомер, под мою монотонную речь, с указаниями реквизитов, которые необходимо заполнить в порядке их заполнения и прочего.

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

– 151 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 руйте, что у вас получилось и все остальное». Ни бе, ни ме. Почему? Люди вводят зарплату один раз в месяц. Каждый раз они начинают судорожно листать свои учебники с вопросом: «А как же зарплата вводится?» Когда у меня таких было 18 юрлиц, мы что сделали? В одном юридическом лице было 100 сотрудников и выделенный специалист по ЗУП, который начислял зарплату, а у остальных это делали главные бухгалтеры. Директор сам видит скорость ввода документа по каждому сотруднику и говорит – «Слушай, а у меня зарплату по всем юрлицам может и один человек начислять».

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

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

• Контроль регистров учета. Здесь понятно.

• Экзамен-тестирование. По-другому – публичная порка. Через две-три недели, после старта (запуска системы) публичное тестирование с представителями владельца, либо с этим владельцем. Конкретно: человек обрисовывает свой документооборот, объясняет, почему таким образом это все заводится и т.д. Здесь есть плюсы – в одной конторе мне удалось на варианте экзамена-тестирования уволить несколько главных бухгалтеров. Потому что я прошу: «Ребята, покажите мне, пожалуйста, как вы начисляете зарплату, проанализи-

• Ввод временных исполнителей. Необходим при жестком саботаже определенного дела. Просто я нанимаю с рынка бухгалтеров, которые проходят это тестирование за двойной оклад, потому что это временная проектная работа. Люди с удовольствием идут, временно со мной работают, проект закрывается, они идут дальше. Некоторые потом говорят: «Алексей, проект будет – звони. С тобой в два раза интереснее».

При такой ситуации судиться с владельцем бизнеса в принципе нет необходимости.

– 152 –

IT due diligence: как ИТ-служба может повысить стоимость компании Франц Бдоян Менеджер отдела анализа и контроля рисков PwC в Санкт-Петербурге

Представлюсь. Меня зовут Франц. Я руковожу практикой анализа и контроля рисков в PwC в Санкт-Петербурге, в регионах. Я также являюсь руководителем института внутренних аудиторов по Северо-Западу. По совместительству работаю еще независимым членом совета директоров одной производственной химической компании.

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

Почему? Давайте на минутку закроем глаза и представим себе, что мы хотим купить замок в Англии, где-нибудь под Манчестером. И нам надо выяснить, правда или нет то, что написано в буклете – что там есть всякие DVD-системы, 50 телевизоров, бесперебойное электропитание и так далее. Чтобы это выяснить, я могу отправить туда своих детей, которые, скорее всего, пришлют мне отчет о том, что там не хватает Xbox-ов, SonyPlayStation, на компьютерах не установлен Warcraft и нет iPad-ов на холодильниках.

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

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

Зачем нужен этот IT Due Diligence? Если вы не против, я также буду называть его ИТ-анализом.

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

• Ну, например, исследование Symantec, которое рассказывает о том, что: —— все компании сталкивались с хакерскими атаками

—— И 98% из них испытывали от этого какие-то материальные потери —— А 46% из-за этого имели существенные простои в работе.

• Другая компания исследовала, что:

—— 50% компаний, которые испытывали действие чрезвычайной ситуации и теряли данные на этом – в течение двух лет просто закрывались

—— А данные другого исследования американского бюро статистики указывает, что в течение пяти лет после подобных чрезвычайных ситуаций, связанных с потерей данных, закрываются почти все подобные компании – 93%.

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

– 153 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 и других платежей. У нас эта цифра может быть больше или меньше, чем в Англии, но от этого нам лучше не становится.

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

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

Поэтому эта тема, на самом деле, очень актуальна. Она смотрит немножко вперед, но уже сейчас видны в этом деле какие-то подвижки.

Что такое ИТ-анализ? Что он в себя включает?

• В первую очередь, аудитор обычно хочет понять, как устроена ИТ-среда

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

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

Может ли комплексный анализ ИТ затронуть и нас? Это, на самом деле, цифры, которые я увидел в нашей российской практике.

• В 2010 году из тех компаний, который проходили в целом финансовый DueDiligence, только 5% проходили еще и ITDueDiligence

• В 2011 году эта цифра увеличилась до 7%

• В 2012 году уже 15% проектов включали в себя ИТ-анализ.

Что происходит в Великобритании, где это уже поставлено на конвейер?

• в 2012 году в 80% случаев при покупке какой-то компании обязательно проводится ИТ-анализ.

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

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

• Направление ИТ-анализа «Увязка со стратегией и деятельностью компании» (первая колонка).

– 154 –

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

Франц Бдоян

IT due diligence: как ИТ-служба может повысить стоимость компании

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

• Другая область, которая закрывается ИТ-анализом – это «Организация и квалификация сотрудников»

—— Пример: Около двух недель назад я встречался с одним финансовым директором аграрно-промышленной компании, и он мне говорит – «У нас 28 баз 1С, которые администрировались, поддерживались и все изменения, которые были внедрены, – делались одним человеком и этот человек сейчас уволился. Мне нужен кто-то, кто во всем этом разберется». Причем, он приглашал двух отдельных людей, которые просто не разобрались в этом коде и уволились через месяц. Выявление ключевых сотрудников – это одна из основных целей ИТ-анализа. И, как я вижу по этому залу, порядка 500 компаний в эти два дня сталкиваются с теми же проблемами, поскольку их ключевые сотрудники, собственно, находятся здесь.

• По примерам из «Технологии и архитектуры» и «Руководству и корпоративному управлению» – недавно, во время совета директоров, директор по ИТ нашей компании рассказал мне историю о том, что, когда он работал на предыдущем месте работы, там проводили IPO-диагностику. Это делается, оказывается, в течение двух дней, как он сказал. Там пришли и всего за два дня выяснили, что в компании недоинвестируют в ИТ, ввиду этого есть проблемы с информационной безопасностью, с контролями, и пр. И, ввиду этого, им просто пришлось отложить IPO.

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

Примеры выявленных рисков по итогам ИТ-анализа в различных российских компаниях

Еще несколько примеров, которые я взял – специально каждый пример приведен в кавычках, потому что я даже не изменял текст. Здесь приведены примеры выявленных рисков по итогам ИТ-анализа в российских компаниях.

Давайте пройдемся по нескольким самым интересным.

• Например, у нас есть закон о защите персональных данных (152-ФЗ). В нем освещено очень много рисков, контроль над которыми очень важен для иностранных инвесторов. Если кто-то сталкивается с ними, то очень важно об этом помнить

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

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

• Что может быть более интересным для нас сейчас – это, например, «Прямой доступ разработчиков в продуктивную среду использующихся систем». Казалось бы, что здесь такого? Мы же разработчики! Мы вообще аутсорс-провайдеры и мы отвечаем за работоспособность системы. Почему бы нам не дать прямой доступ к этой системе, чтобы с ней работать. Как оказывается – внешний аудитор это будет отмечать как существенный недостаток

• Также еще один факт – «Результаты тестирования изменений, вносимых в информационную систему, не всегда фиксируются, а, следовательно, не могут

– 155 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 быть проконтролированы». Понятно, что тестирование всех изменений обязательно нужно документировать • «Отсутствие разделения сред: разработки, тестирования и продуктивной среды». Казалось бы, вроде обычная вещь, но – внешний аудитор отмечает это как существенный недостаток • Также неограниченный доступ к локальным конфигурационным файлам баз данных у бизнес-пользователей

• и различные недостатки в области разграничений прав и полномочий.

История №1 о роли ИТ-анализа при совершении сделок Хочу еще рассказать несколько историй.

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

Примеры наших рекомендаций в среде контроля ИТ

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

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

История №2 о роли ИТ-анализа при совершении сделок

• «Мы рекомендуем разработать и утвердить политики, стандарты и процедуры, которые бы обеспечивали эффективное управление ИТ». Наверняка, у вас есть положение об отделе. Здесь все немножко шире.

• «Разработать и утвердить Стратегию развития ИТ». Стратегия развития ИТ обязательно должна присутствовать.

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

Другой пример – из области финансовых институтов. Один из крупнейших российских банков пытался приобрести компанию, занимающуюся производством

• «Определить ключевые информационные ресурсы и назначить владельцев этих ресурсов». Когда я с финансовым директором агро-промышленного комплекса говорил про эти 28 баз, я его спросил – «А кто отвечает за эти базы? Кто владелец этого информационного ресурса?» И никакого ответа не последовало, потому что этого просто сделано не было. А владельцы у ключевых информационных ресурсов должны быть.

– 156 –

Франц Бдоян

IT due diligence: как ИТ-служба может повысить стоимость компании

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

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

Примеры наших рекомендаций в сфере эксплуатации компьютерных систем

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

Что в части внедрения и изменения существующих программных продуктов мы обычно рекомендуем?

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

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

• «Рекомендуем разработать детальный план по обеспечению непрерывности бизнеса Компании» – так называемый businesscontinuityplan • «Разработать план действий в части ИТ при возникновении ЧП» – это disasterrecoveryplan

• «Разработать и ввести в действие Регламент по выполнению резервного копирования» – наверняка он у всех есть

• «Уровень физической защиты серверных помещений должен соответствовать требованиям ограничения физического доступа».

• «Обеспечить использование только официальной и лицензионной программной продукции в рабочей среде на предприятии»

Примеры наших рекомендаций касательно разработки и изменения программного обеспечения

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

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

– 157 –

Я аттестованный специалист, или Без бумажки ты букашка! Павел Чистов Методист по платформе 1С:Предприятие 8, сертифицированный преподаватель ЦСО. chistov.pro

От ведущего: Я вам сейчас расскажу историю из своей жизни. В 2003 году я сдавал экзамен на сертификат. Но я же максималист, и я тогда решил, что мне нужны все сертификаты из линейки 1С. И поэтому тогда я сразу начал готовиться на весь спектр – и, в конце концов, вообще ушел в другие платформы. И, самое интересное, что, когда мне уже надо было сдавать экзамен, я почему-то вдруг понял, что мне сертификаты уже не нужны. Так что у меня сейчас нет ни одного сертификата. Правда, я сейчас жалею о том, что тогда пошел таким путем. Если бы я осваивал все по порядку, мне бы чуть легче было. То есть, это моя ошибка. Мне интересно мнение Павла об этой ситуации. Павел, как ты к этому относишься? От докладчика: Я как раз и собираюсь рассказать, как к этому отношусь я и почему у тебя возникло ощущение, что тебе этот сертификат не нужен.

• Или же, например, мне говорят – «К нам пришел человек устраиваться на работу с бумажкой. А он ничего не знает». Из этого следует, что сертификат этот ничего не значит, и человек этот сертификат купил.

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

Виды аттестаций 1С

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

Меня зовут Павел Чистов. Я методист по платформе. Я преподаватель. О чем мой доклад? Я хочу рассказать про сертификаты, о том, зачем они нужны, и почему не нужны сертификаты от 1С (как это ни странно).

Почему возникла тема такого доклада?

Здесь снизу вверх представлены виды аттестаций фирмы 1С. Три ступени: • 1С:Учебное тестирование (соискатель)

• 1С:Профессионал (профессиональный пользователь)

• 1С:Специалист (квалифицированный специалист – программист, консультант)

Здесь перечислены все причины того, почему сертификаты мне не нужны. То, о чем мы с Алексеем только что говорили.

• Я и так знаю, зачем мне эта бумага. Ну, будет она висеть. Но я ведь время потрачу на подготовку. Там нужно же задачи какие-то прорешать, еще чтото, а у меня работы выше крыши. Ну скажите, кто не получил сертификат только потому, что просто нет времени – горит проект. Ведь есть же такие?

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

– 158 –

1С:Профессионал

А вот про 1С:Профессионал хотелось бы отметить.

Павел Чистов

Я аттестованный специалист, или Без бумажки ты букашка! Например, специалист по прикладным решениям. 1С считает, что, если человек сдал этот экзамен, то он уже готов внедрять (дорабатывать) целевую типовую конфигурацию. Но вот смотрите – конфигурации меняются. Человек получил сертификат по 1С:Бухгалтерии 8.0 какой-то лохматой редакции. А сейчас уже вышла на управляемых формах эта бухгалтерия. И что получается? Он – обладатель сертификата. Вот, он пришел устраиваться на работу. Он этот сертификат работодателю показал, и его посадили к клиенту. А работать-то он не может, потому что все по-другому стало.

Сертификат 1С:Специалист-консультант Есть такой сертификат 1С:Профессионал. Все его, наверное, знают и пробовали его сдавать. Раньше на дисках ИТС они публиковались. Вот у меня есть очень любимый вопрос из 7.7. Я его не дословно привел, но он где-то так и выглядит: «Какого цвета галочка на значке проведенного документа, находящегося позже точки актуальности?»

Вот эти галочки здесь изображены. Какого они цвета? Понятно, что не красный. Но такого и не было варианта ответа. Были варианты ответа:

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

• Черный • Серый • Синий

Мы замеряли в Paint специально с коллегами – не подходит ни один. Что проверяет этот вопрос? Угадайка какая-то.

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

Сертификат 1С:Специалист по платформе

Сертификат 1С: Специалист по прикладным решениям

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

Но. Что проверяется? Опять же, у человека есть сертификат 1С:Специалист по платформе, получен-

– 159 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 ный, например, по версии 8.0. Версия 8.0 – это обычное, не управляемое приложение. Сейчас сдают сертификаты 1С:Специалист по версии 8.2. Там появилось управляемое приложение. А этот человек, например, с ним работать не умеет. Для сдачи экзамена 1С:Специалист по платформе проверяется конкретное умение работать с: • Регистрами накопления • Регистрами сведений • Регистрами бухгалтерии • Планами видов характеристик • Запросами • Еще и формы там недавно добавились.

Как вы понимаете, в платформе же механизмов больше.

К чему это приводит? Человек с сертификатами 1С:Специалист приходит в организацию устраиваться на работу и говорит: «Вот я – Специалист!» Ему говорят – «Ну иди настрой там обмен данными между двумя этими базами». Оп-па! А как?

Из всего этого следует, что сертификаты 1С:Специалист имеют недостатки:

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

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

• они, во-первых, как мне кажется, устаревают,

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

Сертификат 1С: Эксперт по технологическим вопросам.

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

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

Сертификат 1С:Руководитель проектов

Если я правильно помню, экзамен на этот сертификат раз в два года сдают. И в 1С считают, что если в команде есть руководитель проектов с такой бумажкой – все, любой проект будет внедрен.

Давайте разбираться. Да, нам нужен какой-то критерий оценки, правильно? Чтобы как-то оценить человека. Как? Это другой вопрос.

• Зачем сертификаты нужны фирмам-франчайзи? Фирмы-франчайзи являются партнерами фирмы 1С, а фирме 1С нужно рейтинг выстраивать, чтобы подстегивать качество предоставляемых услуг в самих этих фирмах франчайзи. Правильно? Правильно.

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

• Работодателю? Приходят два человека. Один с сертификатом, другой без. Кого возьмут? Того, кто умеет работать, совершенно верно. Но если пришло 150 человек и надо быстро принять решение – кого будем проверять? Всех 150 проверять не будем. Будем проверять только тех, у кого есть сертификаты, а там уже будем их сортировать. Правильно?

• Ну и, зачем нужен сертификат специалисту? Совершенно верно, потешить самолюбие.

– 160 –

Павел Чистов

Я аттестованный специалист, или Без бумажки ты букашка!

Отрицательные стороны сертификации

шла 8.1, 8.2, 8.3. А этот человек с этим сертификатом может сказать, что он умеет писать мобильное приложение на 1С:Предприятие? В общем случае – не может. Поэтому, вот эта бумажка не говорит ничего об уровне его компетенции на текущий момент времени.

Вот. Давайте разберем отрицательные стороны сертификации.

Что делать? Почему так в итоге получилось, мы обсуждать не будем.

Я о них уже немного рассказал. Но, давайте еще раз.

• Зазвездившиеся спецы. Когда специалист получает очередной сертификат, у него чувство собственного достоинства от этого вырастает, и он говорит своему работодателю «Хочу больше денег» или, например, раньше он развозил ИТС, а теперь говорит «Да вы чего? У меня сертификат. Я не поеду». И все. Причем, этот специалист будет периодически требовать повышения оплаты – больше, больше и больше. Но, по факту, у него ведь есть только две ступени – нет сертификата, и есть сертификат. А дальше мы уже не можем оценить – развивается он или не развивается.

• Франчайзинговое рабство. Что я под этим подразумеваю? Человек получает сертификат, работая во франчайзи. И на протяжении двух лет он не может перевести этот сертификат без согласия франчайзи или оплаты этому франчайзи определенной суммы денег (1000 условных долларов в первый год или 500 условных долларов во второй год). Причем, довольно интересная ситуация получается в случае, если человек сам, как физлицо, получает сертификат, потому что, когда он приходит работать во франчайзи, его личный сертификат автоматом, без каких-либо дополнительных соглашений, приписывается этому франчайзи. И все. Он опять же, два года не может без согласия этого франчайзи перевести этот сертификат. Правда, мне говорили, что сейчас это поправилось. Поэтому я не берусь утверждать на 100%. Но все равно, у нас такие понятия, как личный сертификат и сертификат франчайзи, отсутствуют.

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

• А самое плохое, как мне кажется, это – универсальность сертификата. Вот мы получили сертификат по платформе 8.0. Он висит у нас на стене. Там написано, что я являюсь мега-супер-специалистом по системе программ 1С:Предприятие 8. Потом вы-

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

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

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

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

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

– 161 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

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

Причины:

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

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

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

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

Как мы можем использовать этот результат оценки?

Что я имею в виду под более детальной сертификацией?

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

• Как я уже сказал – для внутреннего управления кадрами • Для рекламы себя при трудоустройстве

• Для рекламы компании перед заказчиком. Приходит заказчик, а вы ему распечатку даете, и говорите: «наш сотрудник, который будет непосредственно с вами работать, умеет работать вот с этим». И все – вопросов не будет. Допустим, клиент заказал обмен данными с сайтом. Нашли по этим листам, кто умеет работать – дали конкретного сотрудника этому заказчику. И клиент может потом претензию предъявить: «Вот вы мне сказали, что он умеет, а он не умеет. Почему?» И это будет уже адекватная претензия. Потому что вы не просто говорите «Он у нас аттестованный специалист», а говорите конкретно, по каким компетенциям он аттестован.

– 162 –

Павел Чистов

Я аттестованный специалист, или Без бумажки ты букашка!

Соответственно, кто может владеть сертификатом?

отдел экзаменатора. Пускай он сам аттестует их. По-моему, это вполне хорошо.

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

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

Кто бы мог проводить такую аттестацию?

• Компания • Физлицо

• Передача сертификатов на любых договорных условиях

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

Адаптивная технология сдачи

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

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

Альтернативная сертификация. Ценность сертификата

У 1С есть только два формата сдачи сертификации – это либо в самой фирме 1С, либо тоже в фирме 1С, но через интернет – дистанционно, в терминале. Но ведь есть еще много вариантов: • Допустим, компания хочет аттестовать свой отдел. Там 15 человек. Компания приглашает к себе в

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

– 163 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

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

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

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

– 164 –

Мобильная платформа 1С: какие сложности вас ждут и как их обойти Дмитрий Шерстобитов Сооснователь компании DINEVA (Украина), которая занимается разработкой и внедрением программных решений для бизнеса

А на картинке это выглядит вот так:

Наконец осознав важность игры на поле мобильных технологий, известная нам компания из двух букв не так давно выпустила мобильную платформу 1С. Программистский мир «возрадовался» и принялся за создание мобильных приложений. Я не исключение. Но оказалось, что при декларируемых простоте и удобстве на этом тернистом пути нас, тем не менее, ждет много трудностей. Не знаю, как вы, а я провел много времени, пытаясь подружить 1С и Android. Данная статья – итог этого веселого времяпрепровождения. Описывать конкретные версии платформы я, конечно, не буду, ибо пока что, исправляя одну ошибку в старой версии, 1С умудряется допустить пять других ошибок в новой и совсем не хотят следить за выходом новых SDK от Google, которые применяются при компиляции приложения от 1С. Я же остановлюсь на общих проблемах, с которыми столкнулся при работе с мобильной платформой, и вариантах их решения. Некоторые из предлагаемых решений просты, в отдельных случаях придется попотеть. Как бы там ни было, работать с мобильной платформой можно, а мой опыт (и опыт других людей, которые делились им со мной), надеюсь, сделает ваше общение безболезненным. Или не сделает.

«В списках не значился»

Компания 1С не стала юлить и добровольно предоставила список того, что мобильная платформа, в отличие от привычной конфигурации, не может в принципе. Официальный перечень функций, которые не поддерживаются мобильной платформой (копирую с http://v8.1c.ru/overview/Term_000000818.htm#1): • используются не все классы объектов конфигурации;

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

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

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

Отчеты

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

Синхронизация

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

– 165 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 читателям приходилось плотно заниматься распределенными базами, поэтому остановимся на этой теме подробнее (знатоки могут смело пропускать данный параграф).

Берусь утверждать, что синхронизация, при помощи планов обменов ЦБ с мобильным приложением- нетривиальна. Объясню почему.

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

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

Запросы

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

Вспомнив, что объект «Отчеты» нам не доступен, мы бросаемся к конструктору запросов… и понимаем, что жизнь – тлен. Такого объекта как «Запрос» тоже не существует. Не стоит сразу отчаиваться, все не так ужасно: некое подобие на конструктор запросов доступно в динамическом списке, однако работать можно только с одной таблицей данных, и вытягивать дочерние реквизиты через точку – не выйдет. Но это уже что-то.

Пошаговая отладка

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

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

FAQ

Итак, мы разобрали основные проблемы, которые затрудняют работу с мобильной платформой 1С. Теперь перейдем к вариантам их решения в формате «вопрос – ответ». Как получить «тяжелый» отчет на телефоне?

Здесь я предлагаю вам ознакомиться с принципами работы мобильных приложений, описанных мною совместно с коллегами в двух статьях: «1C + Android (конструктор отчетов) v1.5.1» (публикация №152865) и «1C + Android (конструктор отчетов)» (публикация №128699). В первой статье затрагиваются такие темы, как передача параметров на сервер через web-сервис, формирование структуры отчета на сервере и дальнейшая передача его в приложение. По сути это шаблон для вывода отчета в вашей конфигурации под мобильное устройство. Принципы формирования отчета – идентичные. Дополнительно можете разве что архивировать структуру – для уменьшения объема передаваемой информации.

Во второй статье описан немного другой подход: рассматривается алгоритм формирования отчетов на основании пакетов XDTO. Если вы хотите передавать данные,сериализуя объект целиком, как, например, в случае планов обмена или универсального обмена при помощи XML, разобраться с этими пакетами будет не лишне. Кроме того, в хелпе, идущем в архиве к упомянутой статье,рассказывается все, что необходимо знать для создания web-сервиса, его отладки и пр. Также рекомендую к прочтению статью «1С + Андроид (создать связь сейчас сможет даже новичок) + безобъектная модель» (автор –samamoiloff, публикация №154074). Этот материал (а точнее –исходники конфигурации), поможет сформировать представление об обмене данными между массой различных устройств при условии минимального изменения конфигурации.

Лично я проверяю web-сервисы с помощью обработки «Обработка тестирования WEB-сервиса (WSDL)» (автор – KurganPX, публикация №95062). Она написана для обычных форм, но, несмотря на это, очень выручает. Помимо этих статей есть еще масса полезных материалов, ищите по тегам web-сервисы, XDTO пакеты, сериализация, wsdl.

Если вернуться к вопросу, который вынесен в заголовок параграфа, то в двух словах это выглядит так.

– 166 –

Дмитрий Шерстобитов

Мобильная платформа 1С: какие сложности вас ждут и как их обойти

На стороне клиента (например, мобильного приложения) вы формируете набор параметров для отбора данных отчета и отправляете их на сервер при помощи web-сервиса. Сервер формирует ответ в виде сериализации объекта вывода (дерево значений, табличный документ и т.п.) и возвращает его на сторону клиента. Далее клиент десериализует ответ в объект 1С и выводит на экран мобильного устройства. Звучит просто, на деле нужно постараться. Как рекомендует работать с планами обмена 1С(если взять за основу демо-конфигурацию «Заказы», которая доступна на диске ИТС, если мне память не изменяет)?

Итак, каким же образом происходит синхронизация 1С стационарной, с мобильным приложением 1С? Тут надо отдать должное 1С за демо-конфигурацию «Заказы»: там сделано все, что нужно, однако не без нюансов.

За основу обмена данными были взяты планы обмена, однако, если вы считаете, что теперь все отлично, можно смело отложить эту мысль в сторону. Ибо тут возникает ряд проблем, которые частично можно решить, а частично – нет. Начну с того, что разработчики ушли от передачи данных при помощи файлов, для этого они используют web-сервисы (да, теперь они везде, смиритесь). Работает это так: на стороне сервера есть web-сервис «ОбменСМобильнымУстройством», который вызывается с телефона. Обратите внимание на одноименный пакет XDTO, который является залогом успешной работы web-сервиса с 1С на ОС Android (на iOS должно работать и без этого пакета). Вот что происходит в момент вызова синхронизации приложения с центральной базой (ЦБ).

1. Приложение проверяет, является ли оно узлом обмена. Если не является, то создается новый узел обмена, и тут всплывает первый нюанс. Дело в том, что код узла, по которому дальше будет идти идентификация конкретно этого телефона, создан с помощью функции «СистемнаяИнформация», и оттуда же взяты данные «Идентификатор Клиента». Проблема в том, что этот код не такой уж и уникальный, особенно если вы закупили для компании 50 одинаковых мобильных устройств. Посему предлагаю сразу назначать код вручную или же любым другим способом, который позволит соблюсти его уникальность. (В скобках замечу, что в одной из версий разработчики все же исправили эту ошибку, но я бы не рисковал…). Итак, создается узел клиента в приложении и узел ЦБ, и на этом первый этап синхронизации закончен.

Небольшое отступление. Все это работает при помощи функции «НачатьОбмен» в web-сервисе «ОбменСМобильнымУстройством». Этот web-сервис

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

2. Переходим ко второму этапу – получению данных. Здесь притаился второй нюанс: обмен при помощи web-сервисов – это по сути обмен при помощи протокола SOAP, который имеет свои ограничения по времени передачи данных и их объему. Не пытайтесь синхронизировать с приложением всю вашу базу, все равно не выйдет, тем более в первый раз. Запаситесь терпением, отправляйте данные порциями или задайте такой план обмена, при котором приложение может «переварить» информацию. И не забывайте о том, что мобильная связь – это не wi-fi, поэтому видео передавать нежелательно.

Помимо прочего, ограничения есть у мобильного устройства. Например, каждому приложению выделяется определенный объем памяти, и если приложение захочет больше, Android его попросту «убьет» (то же касается и iOS). Конечно, мы делаем поправку на то, что мобильная платформа 1С рассчитана на такие ситуации, но злоупотреблять не стоит. Если же вы захотите передать, например, по почте файл размером 200 Мб, 1С и в этом случае вряд ли его загрузит, правда, многое зависит от версии Android и характеристик телефона.

3. На третьем этапе во всей красоте предстает протокол SOAP и одно из его слабых мест: в момент, когда приложение передало данные на сервер и тот начал их обработку, приложение переходит в режим ожидания ответа. Т. е. оно ждет, пока ЦБ загрузит данные в базу и сформирует ответ, который сервер затем отправит на сторону клиента. Клиент, получив ответ, примет его и загрузит в свою базу данных. Таким образом за одно соединение происходит обмен в обе стороны. И тут нас может подстерегать «эпик фейл»: если одна из операций объемная (по времени), то протокол обмена может вовсе не дождаться ответа и выдаст ошибку. Тем не менее ЦБ к тому времени уже загрузит ваш пакет обмена, и при втором вызове ЦБ просто проверит номер сообщения, увидит, что оно загружено, и начнет сразу генерировать ответ. То есть со второй попытки вы все же имеете большую вероятность получить данные. Так что не забудьте ставить Попытка в этом месте с выводом сообщения пользователю, дабы не пугать его лишний раз, поверьте, ему страхов и так будет хватать с лихвой.

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

– 167 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013 Для работы с мобильным приложением нашу ЦБ на 8.х,7.7 нужно переводить на 8.3? Тут все немного не так. Не стоит воспринимать мобильное приложение как узел ЦБ. Оно больше похоже на просто отдельную базу. Т.е. представьте себе, что вам необходимо связать вашу ЦБ с другой базой на платформе 8.3, т.е. если у вас ЦБ на 8.х, то можете использовать планы обмена (без использования РБД), web-сервисы, файловый обмен эксельками. А вот если у вас ЦБ на 7.7, то тут по идее ничего не изменится.

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

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

В этом случае картина такова:

Что особенного происходит в данном случае? У нас есть центральная база, в которой настроены планы обмена(соответственно мы «гоняем» данные из приложения в ЦБ и обратно), но одновременно у нас есть отдельная база, в которой мы пишем конфигурацию для мобильных телефонов.

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

Минусы такого подхода очевидны: необходимо постоянно переделывать конфигурацию, нужно создавать новые планы обменов и/или web-сервисы и т.д. Т.е. для применения этой схемы лучше иметь программиста в штате. Какие типы поддержки (обновление, распространение) мобильной платформы предлагает 1С?

Начать надо с того, что есть два формата переноса конфигурации на мобильную платформу 1С (так как официального названия не нашел, то придумал свои): • Фиксированная конфигурация • Произвольная конфигурация

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

Эта схема удобна тем, что при использовании планов обмена между ЦБ и промежуточными базами, вы можете использовать схему РБД и/или прикрутить туда правила КД. В этом случае, возможно вам вообще не надо будет конфигурировать ЦБ. А теперь давайте попробуем «упростить» схему: избавимся от промежуточных баз, чтобы все данные передавались сразу в ЦБ.

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

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

Под нее программировать довольно просто: сконфигурировали – опубликовали в web (в конфигураторе: Конфигурация – Мобильное приложение – Публиковать; указываем имя публикации, отличное от имени публикации базы данных, если таковое имеется), затем нажали кнопку «Обновить» на телефоне. Или поставили галочку «Обновлять мобильные приложения» в конфигурации: тогда при входе пользователя в базу на телефоне (при наличии доступа к серверу конфигураций) мобильное приложение само обновит конфигурацию. Не нужно ничего компилировать и обновлять

– 168 –

Дмитрий Шерстобитов

Мобильная платформа 1С: какие сложности вас ждут и как их обойти

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

Это конфигурация, скомпилированная до apk-файла. Соответственно, если вы изменили что-то в конфигурации, вам необходимо всем пользователям отправить этот файлик (вес –около 50Мб, стоит отметить, если мне не изменяет память, что маркеты уже давно переносят только измененные участки кода, что может значительно сократить размер файла при загрузке), и все должны переустановить приложение на телефоне. В этом случае обновится и платформа, и конфигурация. Данные, по идее, должны остаться. Какой вариант распространения конфигурация лучше?

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

Если вы штатный программист, которому дали задание роботизировать группу торговых представителей, то ваш выбор однозначно должен пасть на вариант без компиляции. В этом случае вам достаточно установить на телефон мобильное приложение, которое вы скачали, и добавить в него новую базу, прописав путь к опубликованной конфигурации. Этот вариант подходит также для отладки конфигурации до момента компиляции. Не буду пересказывать статью «Пример создания конфигурации на Android из 1C 8.3»: по мере обновления платформы она постоянно обновляется. Что делать с iOS?

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

поapk-файлу. Только учтите: если вы захотите обновлять конфигурацию, которая опубликована на том же компьютере, не пытайтесь вбивать адрес 127.0.0.1, поскольку у эмулятора он свой. Узнайте IP своего компьютера и убедитесь, что у него открыт порт 80 или какой вы там указали web серверу. В последней версии этого эмулятора появилось много удобных вещей, например теперь вы можете открыть приложение во весь экран. Я хочу работать с мобильными устройствами, но боюсь, что данные «уплывут» в Интернет.

Все решается просто. Вы можете «поднять» SSH-туннель (или VPN-канал) между своим телефоном и сервером. Для доступа в эту сеть используется специальный ключ, который генерируют на стороне сервера. Если у каждого менеджера будет свой ключ, то его (и менеджера, и его ключ) можно будет блокировать в любой момент. Для поднятия безопасного соединения мы используем программу BitviseTunnelier (бесплатна для индивидуального использования). Ее мы устанавливаем на сервер, а рабочим компьютерам ставим клиент от этого же разработчика. На мобильных телефонах под управлением ОС Android мы используем SSH Tunnel, это приложение тоже бесплатно.

Таким образом данные «извне» не доступны. Конкретного человека можно в любой момент отключить от сети.

Резюме (час моей работы – бесценен).

Я остановился на основных проблемах, связанных с созданием конфигурации на мобильной платформе 1С и ее дальнейшим использованием. Платформа постоянно обновляется, и ситуация может значительно измениться, поэтому следите за релизами. Издевался над вашей мечтой в светлое будущее с мобильной платформой от 1С – Дмитрий Шерстобитов (DitriX).

З.Ы. Но все же не все столь плохо, будущее однозначно есть, ибо новый релиз мобильной платформы 1С (8.3.3.42) весит уже 23Mb, а это в два раза меньше начальных размеров. Приложение работает стабильнее, быстрее, долго висит в памяти телефона и т.д.

У меня Nokia 3310,я этим телефоном гвозди забиваю, а к планшетам отношусь с недоверием, но хочу кодить под Android.

В этом случае вы можете скачать эмулятор AndroidBlueStacks(.com) и проводить тесты в нем. Достаточно установить эмулятор и два раза кликнуть

– 169 –