infostart Journal выпуск №2

INFOSTART JOURNAL №2

Ноябрь 2013

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

на платформе 1С:Предприятие».

ООО «Инфостарт»

Санкт-Петербург, 2013

– 3 –

Здравствуйте, коллеги!

Представляю вашему вниманию второй номер журнала Infostart Journal.

Журнал представляет из себя дайджест выступлений до-кладчиков на второй конференции Infostart Event Evolution 2013. Много интересного и полезного материала.

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

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

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

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

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

Увлекательного чтения!

С уважением, Цыденов Доржи

СодержаниеСергей КоцюраПрактические вопросы внедрения и развития автоматизации склада.......................................................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

– 6 –

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

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

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

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

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

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

Вот, собственно, оригинал письма от 5 марта 2006 года, по которому я и зарегистрировался.

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

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

Поэтому я подумал – почему бы во всем этом не по-участвовать? Хуже от этого не будет...

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

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

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

– 7 –

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– 8 –

INFOSTART JOURNAL №2 НОЯБРЬ 2013

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

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

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

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

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

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

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

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

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

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

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

– 9 –


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

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

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

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

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

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

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

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

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

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

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

А в результате это приводит к немаленьким про-блемам.

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

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

– 10 –


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

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

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

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

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

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

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

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

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

–Что делаем? –Слушаем шум дождя!–Не вопрос, но только давайте так: сначала со-

бираем заявки, а потом слушаем шум дождя – от-вечаю им я.

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

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

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

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

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

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

– 11 –


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

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

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

Я для себя выделил следующие общие принципы:• Все считайте. Чем раньше начнете считать, тем

лучше.• Избегайте «бутылочных горлышек». Планируя

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

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

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

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

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

– 12 –


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

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

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

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

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

– 13 –

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

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

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

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

Начнем с начала. Откуда вообще в 1С появились вот эти задачи по производительности, и почему они, в об-щем-то, такие – достаточно непростые.

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

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

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

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

И поэтому ее цель – она усредненная. И возникает вопрос – да, вроде, система работает хорошо. Но что бу-дет, если у нас будет 30 пользователей? Система точно будет работать хорошо?

Что будет, когда пользователей будет 300? Возмож-но ли, чтобы и тогда система работала хорошо? А что будет, когда пользователей будет 3000?

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

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

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

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

– 14 –


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

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

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

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

Это именно та скорость, которую, в общем-то, мы ожидаем от 1С.

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

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

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

И обычно такие пользователи не конкретизируют, они просто говорят: «У нас все сломалось, система не работает!»

Сейчас операция, согласно замерам времени АП-ДЕКС, выполнялась 51 секунду.

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

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

– 15 –

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

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

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

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

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

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

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

Но не стоит торопиться. Рассмотрим второй при-мер.

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

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

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

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

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

– 16 –


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

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

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

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

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

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

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

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

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

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

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

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

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

– 17 –


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

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

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

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

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

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

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

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

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

Пользуясь сервисом, мы находим самый «дол-гий» запрос. И вызываем для него план запроса:

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

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

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

– 18 –


В данном случае – с чего, например, можно начать?

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

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

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

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

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

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

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

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

– 19 –


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

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

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

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

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

Выводы

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

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

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

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

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

– 20 –


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

Достаточно трех:• Мониторинг значений APDEX. Я думаю, все зна-

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

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

собираем те ошибки, которые у нас возникают.

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

В заключение

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

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

– 21 –

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

Сергей СтарыхСистемный архитектор, автор подсистемы «Инструменты разработчика»

Вступление

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

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

Общая информация• Основной сайт подсистемы – devtool1c.ucoz.ru

— На нем обеспечено свободное скачивание — Дополнительно подсистема публикуется на

сайте infostart.ru — Веб-сайты подсистемы сразу находятся любым

поисковиком по запросу «Инструменты разра-ботчика»

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

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

• Интеграция инструментов — Инструменты не просто включаются в подси-

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

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

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

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

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

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

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

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

— Для чего, конечно, придется отключить пол-ную поддержку

— Добавление, обновление и удаление подсисте-мы описано на сайте и проиллюстрировано ви-деороликами

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

• Подсистема бесплатна — В том числе для коммерческого использования — Такая позиция планируется и в будущем

Контекстная подсказкаПервый кирпичик подсистемы. Сначала даже выпу-

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

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

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

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

– 22 –


• Ее можно программно подключать к любому полю текстового документа. Для этого в целевую форму нужно добавить всего несколько функций.

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

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

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

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

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

— при синтаксическом контроле — при выполнении программы

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

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

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

Исследователь объектов и коллекций

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

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

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

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

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

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

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

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

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

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

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

– 23 –

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

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

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

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

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

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

• поддерживает работу с настройкой на стороне сер-вера

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

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

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

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

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

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

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

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

Анализ техножурналаДля полного анализа логов техножурнала произво-

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

• Он автоматически определяет текущие каталоги логов для клиента и сервера

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

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

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

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

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

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

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

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

ставки результатов анализа оператору. Глубина анализа – степень обработки данных жур-

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

– 24 –


Консоль запросовФлагманский инструмент подсистемы. Если для

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

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

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

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

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

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

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

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

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

объект БД в виде параметра• Есть настройка динамического отбора и порядка в

режиме компоновки и построителя,

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

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

Консоль запросов• В инструменте присутствуют обработчики «перед

выполнением», строки и самого результата с кон-текстной подсказкой и возможностью отладки

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

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

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

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

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

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

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

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

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

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

специальный редактор на основе контекстной подсказки

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

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

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

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

– 25 –


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

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

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

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

• ВнешниеНаборыДанных — Также при программном вызове у параметров

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

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

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

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

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

• Исполняемые запросы макета компоновки можно передавать в консоль запросов; это поможет по-нять, например, как настройки компоновки влия-ют на исполняемые запросы и какой из запросов выполняется очень долго

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

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

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

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

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

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

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

вания группировок• Реализована передача выбранных данных из ре-

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

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

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

Консоль кода

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

– 26 –


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

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

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

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

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

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

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

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

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

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

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

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

Редактор объекта БД

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

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

• В нем отображаются все реквизиты и табличные части объекта, включая общие и предопределен-ные

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

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

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

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

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

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

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

Интерфейсная панель

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

• Рассмотрим структуру ее дерева — на первом уровне находятся типы объектов ме-

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

обычно внешних обработок и отчетов

– 27 –


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

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

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

• Предусмотрен фильтр по основному представле-нию объекта

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

— в процессе набора текста фильтра он применя-ется автоматически

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

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

— добавить объект в избранное — открыть

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

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

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

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

• обработку «Поиск и замена значений», которая умеет только заменять значения

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

Рассмотрим возможности инструмента подсистемы.

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

— настраиваемый отбор компоновки — сравнение любого количества реквизитов на

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

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

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

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

• Таблица правил замены ссылок — Позволяет указать пары ссылок «что заменяем

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

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

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

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

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

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

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

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

• После выполнения замены — в случае наличия изменений в проведенных

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

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

– 28 –


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

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

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

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

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

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

— Как ручным подбором — Так и компоновкой данных

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

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

ключение обработки строки — ключевые колонки выбранной таблицы БД

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

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

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

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

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

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

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

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

объект БД в текст в виде параметра• Также есть общая опция перепроведения прове-

денных документов при записи

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

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

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

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

• Функции выполнения произвольного кода — Ду(…) – выполняет код с обращением к параме-

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

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

объект в исследователе объектов или коллекций — функция поддерживает отложенное выполне-

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

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

– 29 –


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

соли запросов• если передан построитель запросов, то от-

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

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

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

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

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

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

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

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

— Анализ этих трасс выполняется в режиме пред-приятия инструментом «Анализ техножурна-ла»

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

— изменения параметров возвращаются в вызы-вающий контекст

— интерактивная

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

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

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

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

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

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

Тестирование метаданных – 2/42Практически при любом изменении конфигурации

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

• Тестирование форм управляемых и обычных — Выполняется создание, открытие и закрытие — К сожалению, не все формы поддерживают не-

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

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

• Тестирование прикладных объектов — Выполняется создание, копирование, запись,

проведение, отмена проведения• Поддерживается тестирование внешних метадан-

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

закциях — Это позволяет запускать тестирование на ра-

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

• Результаты — в основном представляются в виде таблицы с

указанием полного имени модуля и описания ошибки

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

– 30 –

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

Фарит НасиповКонсультант по производственному учету и прикладным инструментам управления www.nasf.ru

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

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

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

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

И тут возникла идея переписать курс в формате кейсов. Результат? Объем продаж вдвое превысил наши ожидания!

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

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

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

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

• Традиционные учебные кейсы (программы MBA)• «Кейсы, которые работают ™»

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

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

Рисунок 1. Структура классического учебного кейса

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

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

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

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

– 31 –

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

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

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

150 страниц – не предел…

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

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

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

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

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

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

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

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

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

Из каких блоков состоит этот кейс? • Первый блок – это блок «TheClient» – описание си-

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

блема, с которой клиент столкнулся;• Третий блок – «TheSolution» – здесь анализиру-

ется, какие варианты могли бы быть применены, какой вариант мы выбрали и почему. Здесь приво-дится также экспертное мнение. Хитрости, ходы, тонкие места и т.д.;

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

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

– 32 –


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

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

Структура кейса, который работает

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

Пункт Суть Содержание пункта Точка конверсии

«TheClient» Ситуация• Описание предприятия, проблемы• Постановка задачи

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

«The Challenge» Экспертиза• Генерация вариантов решения• Анализ вариантов• Выбор лучшего + особенности

Демонстрация экспертизы на директорском уровне Демонстрация экспертизы на техническом уровне

«The Solution» Описание решения • Детали выбранного решения

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

«TheResult» Результаты и эффекты

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

Дожимаем скептиков фактами, отчетами и впечатлениями довольных клиентов

– 33 –


Преимущества подачи с помощью кейсов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Личный опыт – возможность самому «потрогать»: — Пробные образцы (например, «тест-драйв кур-

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

Старт»); — Do-It-Yourself.

• Чужой опыт (социальное подтверждение): — Отзывы; — Примеры внедрений; — Кейсы;

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

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

– 34 –


• Есть примеры

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

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

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

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

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

Отзывы

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

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

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

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

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

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

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

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

Honeymoon. Ограничение по времени сбора отзывов.

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

– 35 –


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

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

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

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

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

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

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

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

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

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

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

«Фишкинг»

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

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

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

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

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

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

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

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

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

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

Здесь то же самое. Берутся узнаваемые для руко-водства ситуации и превращаются в кейсы.

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

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

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

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

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

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

– 36 –


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

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

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

• Доказательства – само наличие кейса со ссылкой на компанию. Реальная фотография, реальные от-зывы клиентов, реальные телефоны и, что самое главное, реальный опыт решения вопросов;

• Примеры – кейс является примером. Это инстру-мент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– 37 –


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

… Где-то еще в 2005 году, когда 1С:Консалтинг был на взлете, бурно обсуждались идеи типового тиражно-го консалтинга. Один из вариантов реализации такого консалтинга – «мелкая нарезка» на мини-кейсы.

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

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

Что дальше: меню

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

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

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

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

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

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

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

– 39 –

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

Сергей ЯковенкоРуководитель ИТ-отдела в крупном российском холдинге

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

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

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

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

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

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

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

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

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

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

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

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

– 40 –


Давайте попробуем задуматься, что же такое долго-срочная составляющая качества?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– 41 –

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

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

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

Здесь, я считаю, бескомпромиссный слайд:• Администратор у системы должен быть. Об этом

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

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

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

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

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

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

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

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

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

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

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

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

Ну а пользователи получают информацию из внешнего мира либо из внутренних процессов.

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

– 42 –


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

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

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

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

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

Здесь изображена форма документа «Поступление товаров и услуг» из демо-версии последнего релиза УПП.

Как вы думаете – сколько на этой форме элементов управления?

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

• 32 кнопки, на которые можно нажать.

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

Это касаемо интерфейса. Это то, с чем работает наш пользователь.

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

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

купок. Чаще всего, пользователь просто видит эти «часики», про которые – он уже знает, что нажми <Ctrl + Alt + Esc>(сними задачу) и запусти заново, и, может быть, все получится.

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

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

Как пользователь узнает систему?

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

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

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

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

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

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

– 43 –


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

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

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

Но все равно – 80% информации в системе дают пользователи, которые в своей жизни используют 5-7 видов операций.

Как нам упростить им жизнь? Ответ банальный. Для них нужно написать инструкцию.

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

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

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

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

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

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

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

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

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

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

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

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

• Функциональная инструкция должна быть по-нятна и доступна пользователям минималь-ного уровня подготовки (базовые навыки ком-пьютера и возможность осуществлять процесс в действительности)

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

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

– 44 –


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

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

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

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

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

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

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

ServiceDesk – служба поддержки пользователей

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

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

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

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

– 45 –


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

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

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

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

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

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

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

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

Процесс изменения и эксплуатации должен быть разделен

Самый последний тезис: «Разделяй и властвуй»

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

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

– 46 –


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

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

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

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

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

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

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

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

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

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

• Не надо обновляемость возводить на уровень важнейшего принципа (пример с нашими дина-мично рисуемыми формами в обычном приложе-нии)

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

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


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

Я не рассмотрел только два:• «Я верю отчетам системы» • «В программе есть что-то лично для меня».

К сказанному еще хочу добавить:• «Нет никакого секретного ингредиента, также,

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

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

– 47 –

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

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

Предыстория

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

Карта памяти 1. Содержание доклада.

Введение

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

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

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

Кому может быть интересно:

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

Что такое кейс?

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

Подход консалтинговой компании McKinsey к управлению проектами

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

– 48 –


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

Карта памяти 2. Секрет McKinsey.

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

Карта памяти 3. Метод McKinsey.

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

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

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

структурирования.

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

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

Инструмент «Логическое дерево»Чаще всего для структурирования используют ин-

струмент – логическое дерево: иерархический список

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

Фреймворки бизнес-ситуацийФреймворк можно представить в виде структуры,

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

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

Карта памяти 4. Фреймворки в McKinsey.

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

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

– 49 –

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

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

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

Выдвижение гипотезы

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

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

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

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

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

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

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

Сбор фактов для подтверждения и опровержения гипотез

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

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

Дерево вопросов для проверки гипотезыДерево вопросов по сути схоже с логическим дере-

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

– 50 –


Управление знаниями в McKinsey

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

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

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

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

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

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

РезюмеКейс (отчет) по McKinsey = (Логическое дерево +

Фреймворк) + Решение + Факты.

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

Решение IBM для IT-проектовТеперь предлагаю рассмотреть развитие идеи

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

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

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

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

Карта памяти 8. Путь IBM.

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

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

Рисунок 1. Индустриальные модели IBM.

– 51 –


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

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

Рисунок 2. Программа IBMm1 с загруженной моделью для Розничного сектора.

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

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

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

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

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

Резюме Кейс по IBM = Фреймворк с готовым набором ана-

литических показателей и измерений.

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

Кейсы проектов для 1СКомпания 1С активно занимается развитием мето-

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

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

– 52 –


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

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

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

Карта памяти 10. 1С:ПрофКейс.

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

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

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

Рисунок 4. Страница кейсов на сайте 1С:Консалтинг.

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

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

1. внедрить инструменты по управлению проектами в текущие конфигурации, как это сделано в SAP, и с помощью этих инструментов собирать кейсы проектов в единой базе знаний (после обработки данных экспертом);

2. проработать юридические вопросы, касающиеся конфиденциальности передаваемой в кейсах ин-формации, чтобы не допустить ущерба Клиенту;

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

Какой может быть результат?1. «очищенные» кейсы проектов, с которыми могли

бы знакомиться 1С специалисты перед запуском проектов;

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

3. лучшие отраслевые практики.

Фреймворк кейса проекта

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

– 53 –


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

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

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

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

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

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

Торговля

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

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

Логистика

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

Карта памяти 16. Пример кейса проекта 1С для внедре-ния WMS-системы с точки зрения бизнес-аналитика.

– 54 –


Производство

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

Карта памяти 17. Пример кейса проекта 1С в произ-водстве с точки зрения бизнес-аналитика.

Заключение

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

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

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

Источники информации:1. Инструменты McKinsey. Лучшая практика реше-

ния бизнес-проблем | Итан Расиел и Пол Фрига2. Метод McKinsey. Использование техник ведущих

стратегических консультантов для решения личных и деловых задач | Итан Расиел

3. Золотые правила Гарварда и McKinsey. Принцип пирамиды в мышлении, деловом письме и уст-ных выступлениях | Барбара Минто

4. Цель. Процесс непрерывного улучшения | Элия Голдратт, Джефф Кокс

5. Найти идею. Введение в ТРИЗ – теорию решения изобретательских задач | Генрих Альтшуллер

6. Вебсайт IBM. Introduction to IBM Industry Models7. 1С: Консалтинг8. 1С: Технология быстрого результата9. Курс ИТРП «Как избежать ошибок на проектах»10. Инфостарт. Статья «Как не нужно запускать про-

екты»

– 55 –

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

Михаил ХаритоновДиректор компании 2iS, автор Конвертации данных

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

От докладчика: Политику надо вспомнить... Как это происходит в стране? Есть президент, есть регио-нальное управление…

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

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

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

как с этим связана SOA (сервис-ориентирован-ная архитектура). Для кого это актуально.

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

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

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

— Концепции — Преимуществах — Архитектуре (на пальцах)

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

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

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

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

Личные достижения

Немного о личных достижениях. • Четыре года работал в компании 1С в должности

руководителя направления интеграции при-кладных решений – с 2000 по 2004 год.

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

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

– 56 –


— Вы можете видеть на ИТС написанный мною «Универсальный бухгалтерский отчет для 7.7»,

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

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

— «Универсальный обмен данными в формате XML»,

— Стандарты обмена CommerceML (2000 год – xdr, 2003 года – xsd).

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

• механизм HRM-анкетирования в ЗУП,• и работа через интернет со штрих кодами в УТ.• В 1С мною была разработана система внутрикор-

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

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

О компании 2is• Компания образовалась в 2004 году. Мне не хва-

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

• Компания 2is специализируется на крупных про-ектах, по тематикам

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

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

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

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

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

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

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

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

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

(сервис-ориентированной архитектурой)? Что такое SOA?

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

– 57 –

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

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

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

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

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

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

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

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

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

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

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

Манифест SOA

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

Она постулирует, что:• отдача для бизнеса важнее технологической

стратегии, • стратегические цели компании важнее выгод,

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

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

– 58 –


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

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

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

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

Мировая практика.

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

Был проведен анализ существующих решений на рынке:

• IBM WebSphere• Microsoft BizTalk Server• Software AG webMethods• Oracle Enterprise Service Bus• SAP Net Weaver

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

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

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

системам и заставляя их работать в едином «оркестре»?

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

• Управление обменом данными во всех его интер-претациях:

— С использованием правил конвертации, раз-работанных в конфигурации «Конвертация данных» \ Без использования правил кон-вертации – для одинаковых конфигураций распределенных баз данных.

— С использованием узлов планов обмена \ Без использования узлов – например, динамиче-скими выборками документы за месяц с отбо-ром по определенному складу или юр. лицу. В центре выполнили все настройки – обмен зара-ботал на периферии («Интеграция» позволяет выстраивать сеть из распределенных управля-ющих инфосистем). Еще раз хочу отметить, что модификации управляемых конфигураций не требуется, не требуется их снимать с поддерж-ки,все настраивается во внешней управля-ющей базе «Интеграции». Именно в эту базу импортируются xml-правила для конвертации данных при обмене, она также содержит в себе универсальную обработку обмена, которая по расписанию запускается в управляемых базах, заставляя их выгружать данные, либо друг для друга, либо интеграция работает в режиме «Шина», то есть закачивает в себя все данные и внутри диспетчеризует – кому какой объект раздать. Масштабирование достигну-то серьезное. На ряде проектов удалось обмен ускорить и заставить работать так, как требо-вал бизнес. Например, на проекте «Автомир» порядка 45 дилерских центров в разных горо-дах России и СНГ. Центральная база – Финансы и управленческий учет. Все филиалы со своими многочисленными базами разных конфигу-раций 1С и не только 1С. Автосервис с учетом запчастей работает, кафе при нем, продажа по-держанных автомобилей, страховщики тут же сидят, гаишники… У всех из них свои базы и все это консолидируется в центральной базе. Руко-водство сказало – с каждым филиалом цикл об-мена хотим 5 минут. Результат был достигнут таким образом, что все данные со всех точек сначала собираются в некий «шлюз», пред-ставляющий из себя N справочников одинако-вой структуры для промежуточного хранения

– 59 –


XDTO-объектов – никаких блокировок при обмене! Потом отдельные параллельные за-дания (для удобства понимания можно сказать «регламентные задания») принимают (запи-сывают по таблицам) данные разных типов с разной периодичностью. То есть,мы раздели-ли приемку /и быструю раздачу данных фи-лиалам,и уже обработку/подкачку данных в центре из промежуточного хранилища (шины). Понятно, что регистр бухгалтерии – не резино-вый. 40 параллельных пользователей он никог-да не потянет. У него архитектура такая…

— Режим «дозакачки» больших пакетов – про-должение загрузки с места остановки в случае прерывания. Допустим, мы зареги-стрировали все документы за месяц, чтобы их перекачать, на ночь оставили – 3 Гб закачалось – в 2 часа ночи сервер перезагрузился (забыли учесть, что в это время резервное копирование идет средствами 1С), поэтому режим дозакачки в этом плане очень помогает. Сервер восстано-вился – и, с того места, где процесс прервался – он снова продолжается. К утру все документы закачаны.

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

— Транспортный режим обмена – Интеграция выступает как шина и маршрутизатор для объ-ектов данных.

• Управление любыми прикладными обработка-ми данных в инфобазах

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

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

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

• Управление рассылками отчетов — В том числе сводные отчеты, формируемые

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

• SMS и e-mail оповещения — Мониторинг объектов инфобаз – информиро-

вание об изменениях ключевых объектов. — Произвольные условия контроля – рассылки

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

Настройка сервисов-обработчиков входящей по-чты (примеры [email protected], [email protected], [email protected] ). Для примера – как настроено у нас в 2iS:

По каждому письму, полученному на ящик [email protected] система «Интеграция» автоматически создает в базе ведения учета задачи, формирует до-кументы типа ТЗ. При этом заполняет реквизиты из письма. В письме можно написать «Проект = УТ, Кому = Харитонов» и распознанные системой значения из письма будут записаны в соответствующие объекты.

Входящие письма на ящик [email protected] автомати-чески помещаются в «1С:Документооборот». Напра-вил файл Excel на такую почту – а он в Документообо-рот записался.

Входящие письма на ящик [email protected] – записы-ваются в виде html в нашу базу. Очень удобно, html закачивается с картинками, потом в базе это можно использовать.

– 60 –


Клиентам мы позиционируем наше решение как новый уровень информационной безопасности. Су-дите сами:

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

• Единое хранилище журналов регистрации инфор-мационных баз

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

— Отчет по истории изменений и перемеще-ний конкретного объекта в разных базах

• Контроль аварийных состояний регламентных за-даний инфобаз. Управляется централизованно.

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

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

— Регулярные тесты и замеры (открытие форм, запись объектов, проведение и т.д.)

• Сверка данных между базами, причем разнесен-ных по разным площадкам. Инструменты синхро-низации

• Единый центр администрирования инфобаз — Встроенная консоль серверов 1С, из которой

можно регистрировать все нужные объекты инфраструктуры 1С (центральные серверы, кластеры, инфобазы)

— Выгрузка конфигурации \ Загрузка и Обнов-ление конфигурации из файла или хранили-ща

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

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

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

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

– 61 –


Здесь видны «всплески» – иногда сервер перегру-жен (по оси Y – это миллисекунды). Можно настроить автоматическое оповещение, если график выходит за рамки настроенной вилки значений.

Отчет по автозаданиям

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

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

Благодаря чему это все возникло? Перейдем к тео-ретическим аспектам.

Новая парадигма сервис-ориентированного

программирования

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

Что это такое? Я думаю, что через пару-тройку лет (5-10 лет – примечание редактора)мы все придем к версии 1С-10 и она будет построена именно по такому принципу. Давайте рассмотрим суть новой парадигмы на пальцах и в картинках:

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

— Гранулой является одна функция («алгоритм», «сервис»). По-старому это называлось «Ал-горитмы», сейчас у нас этот справочник на-зывается «Сервисы». В качестве элементов справочника – максимально подробно деклара-тивно описанный реляционными средствами программный код (в таблицах СУБД).• Входные \ выходные параметры• Внешние ссылки на объекты определен-

– 62 –


ной базы (внутренние параметры – констан-ты сервиса)

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

• Ссылки на используемые сервисные объ-екты (Запросы, СКДи другие). Запросы хра-нятся в отдельном справочнике с параме-трами, схемы компоновок во втором, схемы XML в третьем и так далее – на одном из следующих слайдов будет (целая простыня из текущих, существующих в системе сер-висных типов), то есть того, что в одной базе хранится централизованно, но может испол-няться и ипользоваться в любых базах при помощи специального мобильного движка.

• Хранимые централизованно сервисы (параметри-зованные алгоритмы)

— Могут исполняться в любых конфигурациях любых инфобаз (без их модификации)• При помощи внешней обработки Сер-

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

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

• Выполнение сервисов осуществляется строго в изолированном контексте. Чтобы никаких пере-сечений имен не возникало.

Преимущества парадигмы сервис-ориентированного

программирования

• Прозрачность. Реляционные связи — Дерево подчиненности сервисов (параметризо-

ванных алгоритмов)• Какие сервисы использует данный сервис

(рекурсивно)• Какие сервисы используют данный сервис

(тоже рекурсивно)• Полноценный контроль ссылочной целостности

— Нет необходимости использовать предопреде-ленные элементы, НайтиПоКоду() и подобные, то есть – все ссылки добавили, в базе их сохра-нили, код на них ссылается, код их выполняет.

• Быстрый глобальный отбор \ поиск — По именам \ По скриптам \ По подсистемам.

Например, нам нужно найти, как используется метод «УдалитьРегистрациюИзменений». На-брали в справочнике – сразу список 25 функ-ций, где этот метод используется. Посмотрели код, подобрали, скопировали, сделали свой.

• Авторство \ История изменений \ Версиони-рование каждого объекта разработки (до уров-ня каждой процедуры \ функции, то есть сервиса по-нашему)

• Стандартные реквизиты объектов разработки — Статус \ Пиктограмма \ Метаобъект \ Коммен-

тарий \ Подсистема \ Порядок \ Участники \Даты и другие

• Автодокументирование (генерация документа-ции по любым сервисным объектам).

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

• Трассировки, замеры производительности, оп-тимизация

• Инструменты по быстрой и удобной разработ-ке сервисов сами являются сервисами и могут

– 63 –


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

• Диалоги-мастера по вставке вызовов одних сер-висов из других сервисов

• Генераторы шаблонов кода• Синтаксический контроль программного кода• Синтаксическая подсказка при написании про-

граммного кода• Подключение синтакс-помощника по встроен-

ному языку• Проверки соблюдения стандартов разработки

— Он-лайн (Перед записью сервисного объекта) — Офф-лайн (Автоматизированные пакетные

проверки)

Классификация сервисных объектов

Вот та самая простыня сервисных объектов, о кото-рой я вам говорил:

Есть обязательные сервисные объекты – на-пример, объекты метаданных всех систем (мы, как и все остальные, храним их централизованно).

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

Использование в сервисе других сервисов

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

Структура сервиса

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

– 64 –


На закладке «Реквизиты» указан ответственный для каждой функции, документатор, разработчик.

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

Хроника становления сервис-ориентированной

парадигмы программирования

• 2001 год – Конвертация данных, ред. 1 (версия 7.7) — Справочник «Скрипты». Генератор программ-

ного кода. Интерфейсная обработка вызываю-щая другую, использующую директиву #Загру-зитьИзФайла – полностью генерируемую. Пока – никакой параметризации.

• 2003 год – Первые версии параметризованных ал-горитмов

— КД ред. 2 – Инкапсуляция в xml-правилах обмена внешних обработок, Алгоритмов и Запросов, которые передаются в любую базу и там начинают выполняться.

— Типовые операции «1С:Бухгалтерии 8» (там предусмотрены встроенные алгоритмы Прове-дения и ПриИзмененииПараметра – уже с пара-метрами)

— Конфигурация тестирования платформы (несколько тысяч параметризованных Unit-те-стов). Отдел разработки 1С дружно писал тесты

по платформе – еще тогда бета-версия была. Несколько тысяч параметризованных Unit-те-стов – каждый отдел тестировал объекты своей подсистемы. Здесь уже алгоритмы появились с параметрами.

• 2004 год – Сеть из15 магазинов фирмы «Реалист». Первая версия УТ++.Мы использовали наши на-работки в боевых условиях проекта.

— Основная логика Прикладная и Интеграцион-ная вынесена в параметризованный справоч-ник Алгоритмы (пример, алгоритм РасчетЦены – сложный алгоритм с большим количеством ветвлений – наценка зависит от вида одежды, бренда, ткани, размерной сетки и так далее). Научили писать простой код 1С продуктового менеджера – он добавляет новый бренд, пишет, если бренд такой-то, то скидка 10. То есть, по сравнению с огромными сложными параме-трическими настройками, которые постоянно в УТ меняются (там типы цен появились, здесь – расчетные – этот тип на этом…), мы сделали все проще – длинный, но прозрачный код, кото-рый человек едва знакомый с программирова-нием поймет. Даже циклов нет. Главное – писать Если…ИначеЕсли – все очень просто получается.• Репликация программного кода из центра по

15 периферийным базам — Событийная модель подписок на Алгоритмы

(для объектов и форм)• Централизованное управление регистраци-

ей изменений (ПередЗаписью объектов)• 2005 год – первая версия «БСП» от 2is. Текстиль-

ный холдинг «Арбен» ГК «Эликс» — Выделены основные объекты ядра, на базе

которых строятся все последующие приклад-ные решения. То есть,ядро с этими алгоритма-ми (и необходимыми сервисными объектами) мы начали вставлять в типовые конфигура-ции…

• 2007 год – Консолидация «Пятерочки» и «Пере-крестка» (X5RetailGroup)

— МСФО. Мастер-данные. Интеграция БП++ на SOA архитектуре. В сильно доработанную вер-сию «1С:Бухгалтерия 8» добавили ядро сервис-ных объектов (алгоритмы, запросы, схемы…)

— Сеть Цвет Диванов (70 салонов) – УПП + Ядро 2is

• 2008 год – Проект «Автомир». На должность си-стемного архитектора принят Старых Сергей. На-чалась новая веха.

— Ядро почти полностью переписано — Реализована Объектно-ориентированная

сервисная модель• Наследование параметров \ Инкапсуляция

(изоляция контекстов всех алгоритмов). Пример наследования: Объект базы данных

– 65 –


–>Ссылочный объект (->СправочникСсылка) – свою какую-то классификацию добавля-ем…- наследуются параметры, методы и дру-гие свойства.

— Отладка сервисов в конфигураторе (генера-ция внешних обработок для каждого алгорит-ма-сервиса)

— Переименование справочника параметри-зованных Алгоритмов в Сервисы

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

— Централизованное управление выполнени-ем сервисов в разных базах разных конфигу-раций

— В ГК «Автомир» внедрена схема масштабируе-мых обменов – Шина интеграции• Раздельные и параллельные доставка и об-

работка данных• 2011 год – Проект удаленных вызовов мобильно-

го сервисного процессора через Веб-сервисы• 2012 год – Система централизации переписана с

нуля на управляемом приложении — Первая версия продукта «2is:Интеграция»

Новый расширяемый сервис-ориентированный язык программирования

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

Видите, как он может выглядеть? На самом деле вы видите прототип и вполне рабочий, который пишется на специальной разновидности HTML. При исполне-нии, такой xmsl-код транслируется в язык 1С.

На рисунке, в первой строчке, мы определили за-прос (вставляется гиперссылка на элемент справоч-ника Запросы – соответствующий запрос), по этой гиперссылке щелкаем,запрос открывается красиво, в консоли запросов со всеми необходимыми инструмен-тами для отладки этого запроса… Объявили параме-тры – во второй строке, параметру присвоили ссылку на объект базы данных. В третьей строке – вызвали сервис, передали в него запрос, вернулась ТЗ (таблица значений). Можем выполнять код по схеме,где к каждо-му элементу схемы привязан сервис.

Сквозные бизнес-процессы в гетерогенной среде

И последний слайд «будущего» – это вообще у нас готовый прототип, и уже опробованный (работающий) – сквозные бизнес-процессы в гетерогенной среде.

Рисуется графическая схема в справочнике графи-ческих схем. Каждый элемент этой схемы привязыва-ется к выполнению сервиса с настройками в опреде-ленной базе. Нарисовали – появился новый договор в системе «Документооборот». Согласован/нет? Ждем. Система каждый час проверяет, его долбит в системе, ждет. Согласовался? О! – Передала его в другую систему – в Бухгалтерию.

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

– 66 –

Bugsmustdie или как повысить качество конфигураций на платформе 1С:Предприятие 8.х инструментами тестирования

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

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

От докладчика: «Будет счастье».

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

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

Наша компания и ее миссия

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

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

работка инструментария для автоматизации этого процесса.

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

Почему именно наша компания?

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

Зачем говорить про тестирование и зачем оно необходимо?

Все представители сообщества Инфостарт связаны или с IT-сферой, или с бизнесом.

• Для бизнеса принципиально важно быстро вне-дрять.

• Для большинства сфер деятельности важна и критична стабильность работы информацион-ных систем.

– 67 –

Bugsmustdie или как повысить качество конфигураций Евгений Шумилов на платформе 1С:Предприятие 8.х инструментами тестирования

• Соответственно, повышение качества может привести к конкурентным преимуществам.

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

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

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

• Первое и, наверное, самое главное, – правильное проектирование программных продуктов.

• Далее – качественное тестирование всего соз-данного или доработанного функционала.

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

Условные обозначения

Далее в презентации будут использоваться следую-щие условные обозначения:

• Программы• Ошибки• Тестировщики. Так их принято называть во всем

мире, это придумали не мы J

Что такое тестирование?

Для термина «тестирование» есть разные опреде-ления, но, наверное, самое правильное:

Тестирование – это процесс обнаружения оши-бок.

Ручное тестирование

В чем проблема ручного тестирования? Простой пример: протестировать УПП вручную практически невозможно.

• Это очень длительный процесс. • Это очень скучный и монотонный процесс. Через

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

– 68 –


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

Что такое «ошибка»

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

Есть большое количество различных видов оши-бок.

Методы классификации ошибок.

Чтобы эффективно находить ошибки, необходимо их изучать и классифицировать.

К основным способам классификации можно отне-сти:

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

Время внесения ошибок в программу

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

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

• Методологические, логические, ошибки проек-тирования.

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

• И самый неприятный для пользователей класс ошибок – это ошибки, которые возникают во-время выполнения программы.

Устойчивость и скрытность ошибок

По устойчивости ошибки тоже можно классифици-ровать:

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

– 69 –


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

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

Среда обитания ошибок

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

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

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

Виды тестирования для обнаружения ошибок

Какие есть виды тестирования для обнаружения различных классов ошибок?

• Unit-тестирование• Функциональное тестирование• Регрессионное тестирование• Нагрузочное тестирование• …

Многие из этих видов тестирования можно авто-матизировать различными методами.

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

Методы тестирования

Продолжим классификацию методов тестирова-ния. Есть два основных варианта тестирования:

• Ручное тестирование. • Автоматическое тестирование.

– 70 –


Степени сложности автоматического тестирования

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

Можно выделить следующие виды автоматизации:• Есть инструменты для тестирования, которые ра-

ботают полностью автономно• Есть продукты для тестирования, которые требу-

ют наличия специалиста — В самом простом случае – это оператор низкой

квалификации — Для каких-то видов тестирования требуется

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

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

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

Как тестируют на 1С

Сейчас в мире 1С самый распространенный спо-соб тестирования – это тестирование с помощью пользователей. На самом деле, это самый эффектив-ный способ тестирования. Чем больше пользователей начинают использовать «сырую» программу – тем бы-стрее будут найдены все ошибки.

При этом качество конфигураций 1С очень принци-пиально. Иногда некоторые ошибки приводят к про-блемам, и часто – к очень серьезным проблемам.

Тестировать с помощью пользователей можно (и все так и делают), но это неправильно.

Сколько стоит ошибка, которая приводит к тому, что 10 пользователей не могут работать в течение од-ного часа? А если пользователей 100?

Место и роль специалистов по тестированию в мире 1С

Почему мы говорим, что в 1С тестирование произ-водится с помощью пользователей?

Давайте посмотрим статистику кадрового рынка. Ниже представлены данные по вакансиям, взятые с сайта job.ru. На диаграмме показано, сколько разме-щено вакансий программистов 1С и программистов из других сфер. И, для сравнения, вакансии тестировщи-ков. Из диаграммы видно, что на рынке 1С практиче-ски нет специалистов по тестированию, и их никто не ищет. Зачем? Пользователи и так все протестируют, и все будет хорошо.

На каких этапах жизни программы можно применять тестирование?

• Проектирование.• Разработка.• Внедрение.• Обновление. Все программные продукты обнов-

ляются в той или иной степени – соответственно можно применять тестирование после обновления

• Поддержка. На этапе поддержки тоже могут быть какие-то модификации, изменения контекста работы программы, смена платформы 1С, смена

– 71 –


операционной системы и так далее. На этом этапе тоже можно применять тестирование.

• Доработки. Любое изменение программы требует тестирования.

Тестировать необходимо на всех этапах.

Инструменты тестирования

Ручное тестирование – это хорошо.

Тестирование пользователями – это тоже неплохо.

Процесс тестирования можно и нужно автомати-зировать, и для этого нужны инструменты.

Далее – переходим к инструментам автоматизации процесса тестирования.

Профессиональных инструментов для тестирова-ния на платформе 1С довольно много. Но многие про них ничего не знают.

Инструменты тестирования производства фирмы «1С»

На текущий момент есть большой класс инстру-ментов тестирования, которые позволяют автомати-чески или автоматизировано находить определенные классы ошибок.

• Первый программный продукт – это «Автомати-зированная проверка конфигураций». Он позво-ляет находить:

— ошибки usability,

— ошибки нарушения стандартов, — наличие различных ошибок в коде метода-

ми статического анализа. • Этот инструмент просто необходим для разработ-

чиков тиражных решений. Если конфигурация не проходит проверку «Автоматизированной провер-кой конфигураций», это очень плохо. По стандар-там разработки фирмы «1С» все конфигурации должны проходить такую проверку

• Программный продукт – «Корпоративный ин-струментальный пакет» (КИП). В нем есть подсистема «Центр управления производи-тельностью», которая позволяет производить нагрузочное тестирование. Его основная задача – поиск и устранение узких мест при работе с SQL сервером.

• Следующий программный продукт – «Сценарное тестирование». Он входит как в «Корпоратив-ный инструментальный пакет», так и распростра-няется самостоятельно. Развитие платформы «1С:Предприятие 8.3» в плане тестирования предназначено именно для улучшения работы этого программного продукта. То есть продукт «Сценарное тестирование» и новые возможности по тестированию в «1С:Предприятие 8.3» работа-ют в связке.

• Следующий программный продукт «1С:Автомати-зированное обновление измененных конфигу-раций, версия ПРОФ» – предназначен, в первую очередь, для тестирования после обновления измененных конфигураций, в которых могут быть проблемы.

• И последний программный продукт «1С:Автома-тическое тестирование конфигураций»

Все эти продукты доступны для приобретения в фирме «1С» и в ее партнерской сети.

– 72 –


Инструменты тестирования производства фирмы «1С-ИжТиСи»

Так как мы очень давно занимаемся тестировани-ем, на текущий момент у нашей компании есть семь различных инструментов, которые позволяют ав-томатизировать поиск ошибок или другие процес-сы в тестировании. Сейчас мы занимаемся разработ-кой еще одного продукта в этой сфере.

• Первый программный продукт, который мы вы-пустили в помощь тестировщикам – это «Управ-ление работой приложений в операционной системе с использованием имитации работы пользователей». Фактически данный продукт представляет собой сценарное тестирование на уровне операционной системы. Он позволяет ав-томатизировать тестирование любой программы на уровне операционной системы. Этот продукт может тестировать как конфигурации 1С, так и любые другие приложения, которые работают на операционной системе Windows.

• Далее, очень специфичный программный продукт «Автоматизированная система протоколиро-вания и разрешения инцидентов», который позволяет обеспечить непрерывную работу пред-приятия. Он позволяет добиться того, чтобы поль-зователи, в принципе, не видели ошибки конфигу-рации. Его основной функционал:

— автоматическое фиксирование и блокировка всех ошибок времени выполнения конфигура-ций

— возможность за счет «горячей замены кода» исправлять различные классы ошибок без пе-резапуска информационной базы

• Следующий программный продукт «Unit-тестиро-вание». В основном, он предназначен для разра-ботчиков тиражных решений и тех, кто применяет методологию «Разработка через тестирование», то есть TDD (Артур Аюханов рассказывал про это на предыдущей конференции).

• Еще один специфический программный продукт «Проверка дистрибутивов», предназначенный для проверки корректности дистрибутивов ти-ражируемых конфигураций 1С.

Инструменты тестирования от других производителей

• Есть программный продукт «Нагрузочное тести-рование» производства фирмы «Рарус».

• На Инфостарте есть ряд обработок, которые по-зволяют автоматизировать какие-то процессы те-стирования.

Наверное, есть еще какие-либо разработки, специ-ализированные именно для тестирования на платфор-ме 1С, но я про них не знаю. Если кто-то знает про них – напишите, мы будем их изучать.

Далее немного более подробно по каждому про-дукту.

Автоматизированная проверка конфигураций

«Автоматизированная проверка конфигураций», в первую очередь, это инструмент разработчиков, то есть тех людей, которые пишут новые конфигурации или развивают существующие тиражные решения.

Данный продукт работает автоматически и пол-ностью автономно, никакая настройка оператором не требуется, также не требуется специалист для на-блюдения за работой программы.

Список ошибок, которые он может находить:• Ошибки проектирования• Синтаксические ошибки• Ошибки нарушения стандартов разработки, пу-

бликуемые фирмой 1С• На текущий момент это единственный продукт,

который позволяет частично тестировать usability. В нем тестируется ограниченный класс ошибок usability, но, тем не менее, какие-то ошибки он на-ходит.

• Этот же программный продукт делает ряд прове-рок по определению проблем с данными.

Этот программный продукт можно использовать на этапе проектирования и разработки.

Продукт распространяется бесплатно фирмой «1С».

– 73 –


Корпоративный инструментальный пакет Центр управления производительностью

Следующий программный продукт – «Корпоратив-ный инструментальный пакет» и, в частности, его под-система «Центр управления производительностью».

Список ошибок, которые позволяет находить этот программный продукт:

• Архитектурные ошибки.

• Ошибки времени выполнения, связанные с про-изводительностью конфигураций на конкретных информационных базах, конкретном оборудова-нии и конфигурациях операционных систем и SQL серверов.

Основное назначение – нагрузочное тестирование. Данный программный продукт довольно сложный.

Для использования программного продукта «Центр управления производительностью» требуется очень квалифицированный специалист. В большин-стве случаев это специалист уровня 1С:Эксперт. Таких специалистов очень мало.

По факту, использовать этот программный продукт можно только во время работы уже конкретного пред-приятия, когда возникают проблемы с производитель-ностью. Применение этого программного продукта возможно на этапах внедрения и поддержки.

Сценарное тестирование

Следующий программный продукт – «Сценарное тестирование». Один из самых первых продуктов на платформе 1С, предназначенный для тестирования.

Этот программный продукт позволяет добивать-ся стабилизации работы программ. Находит ошибки времени выполнения.

Основная проблема данного продукта в том, что для его настройки необходимы очень большие тру-дозатраты специалистов, которые:

• сначала настраивают, • после этого контролируют работу, • а после (при модификации программных продук-

тов) поддерживают и модифицируют тесты-сце-нарии.

Для тестирования любого нового функционала не-обходимо сначала создать сценарий тестирования, при этом фактически выполнив ручное тестирование.

Этот программный продукт можно отнести к юнит-тестированию и к функциональному тестиро-ванию.

Применять программный продукт «Сценарное тестирование» можно только на этапе разработки и различных доработок тиражных конфигураций. Опыта применения этого программного продукта на конкретных предприятиях немного.

Автоматизированное обновление измененных конфигураций,

версия ПРОФ

Следующий программный продукт в основном предназначен для тестирования после обновлений сложных измененных конфигураций. Это «1С:Автома-тизированное обновление измененных конфигураций. ПРОФ». Если быть более точным, подсистема тестиро-вания, включенная в данный инструмент.

Его работа полностью автономна, тестирование полностью автоматическое.

– 74 –


Не требует знания методологии работы тестиру-емой конфигурации. Не требует знания, как работает конфигурация, какие в ней есть функции, объекты и их взаимосвязи.

Позволяет находить множество различных оши-бок.

Применяется на этапе разработки, внедрения, поддержки и обновления.

Автоматическое тестирование конфигураций

На основе предыдущего продукта сделана отдель-ная конфигурация, которая предназначена только для тестирования. У данного продукта более широкий класс применения с точки зрения тестирования. Но опытный специалист сможет применять обе эти кон-фигурации одинаково.

Программный продукт «1С:Автоматическое тести-рование конфигураций» также тестирует любые кон-фигурации на платформе 1С полностью автоматиче-ски и полностью автономно.

После работы этого программного продукта по-является список ошибок, контекст, в котором эти ошибки произошли, а также последовательность действий, которые приводят к этой конкретной ошибке.

Преимущества автоматического тестирования

Минимальное участие человека во время тести-рования – это принципиально. Для статистики, мы проводим 600 тестирований конфигураций. У нас этим занимаются два человека. При этом мы тестируем кон-фигурации принципиально разные. У нас более 200 различных конфигураций, которые мы тестируем. И те два человека, которые занимаются тестированием этих конфигураций, в принципе, не могут знать все эти конфигурации, как они работают, их нюансы и т.д.

При этом часто мы получаем интересные отзывы от заказчиков тестирования. Для примера приведу один случай. Сложный проект, итерации делаются раз в неделю. Заказчиком осуществляется ручное тести-рование силами двух методистов, которые знают все о внедряемой конфигурации. Когда мы выслали им спи-сок из 40 ошибок свежего релиза, они спросили: «Как Вы это сделали?»

Роль нашей компании в развитии программных продуктов

«Автоматизированное обновление измененных конфигураций»

и «Автоматическое тестирование конфигураций»

Продукты «1С:Автоматизированное обновление измененных конфигураций» и «1С:Автоматическое те-стирование конфигураций» – это продукты производ-ства фирмы «1С». Но разработкой и развитием этих продуктов занимается наша компания.

Мы постоянно изучаем новые ошибки, классифи-цируем их и пытаемся добиться их автоматического нахождения.

Основной принцип работы данных программных продуктов:

• автоматический анализ конфигураций• автоматическая генерация сценариев тестиро-

вания• последующее автоматическое исполнение сгене-

рированных сценариев

– 75 –


• автоматическое протоколирование всех найден-ных ошибок без остановки тестирования.

Эти продукты содержат довольно важный функци-онал с точки зрения тестирования. После своей рабо-ты они выводят отчет о том, какой функционал, какие функции и операции были протестированы, а какие протестировать автоматически не получилось. При этом инструменты пытаются определить причину, по-чему не получилось выполнить тестирование, а опера-тор может исключить эту причину, что-то изменив в информационной базе, и заново запустить тестирова-ние нужных объектов.

Управление работой приложений в ОС с использованием имитации работы

пользователей (Сценарное тестирование

на уровне операционной системы)

Следующий программный продукт – универсаль-ный с точки зрения тестирования.

Он позволяет тестировать любое программное обеспечение на уровне операционной системы. За счет того, что происходит полная имитация работы пользователя в любых программах. Выполнение про-грамм контролируется с помощью различных механиз-мов предусмотренных в инструменте, можно тестиро-вать:

• любые конфигурации в режиме «Предприятие», в толстом, тонком, веб-клиентах

• можно тестировать и выполнять различные опе-рации в режиме «Конфигуратора»

• можно тестировать операции такие, как установка защиты, каких-либо других приложений

• как работают какие-то службы и сервисы.

Этот программный продукт основан на полной имитации работы пользователя на уровне операци-онной системы, то есть он позволяет определять, что происходит на экране. Он может за пользователя нажимать в определенные области экрана, выпол-нять различные операции с использованием ком-пьютерной мыши и клавиатуры, ожидать каких-ли-бо событий.

Также он контекстно-зависимый. В зависимости от каких-то ситуаций, сценарии тестирования могут от-рабатывать по-разному.

Требуется ручная настройка. В каких-то сложных случаях требуется программирование. И в определен-ных случаях требуется оператор для того, чтобы смо-треть, что происходит во время тестирования.

Дополнительное применение данного продукта заключается в том, что с его помощью можно автома-тизировать различные повторяющиеся длительные операции, особенно если нет открытых apiили их ис-пользование очень сложное и их использование тре-бует программирования не на языке 1С. Например, мы автоматизировали с его помощью ряд операций таких, как создание большого количества различных информационных баз, автоматическое создание и под-ключение к хранилищу, установка и удаление ключей и драйверов защиты, мониторинг доступности раз-личных сервисов, контроль над стабильностью работы продолжительных вычислений и т.д.

Автоматизированная система протоколирования и разрешения инцидентов

Программный продукт, который предназначен для компаний, у которых жесткий график работы (24/7), и возникновение любой ошибки может очень серьезно

– 76 –


сказаться на деятельности организации. Ведь останов-ка большой компании на 10 минут или на час может обходиться для бизнеса очень дорого.

Этот программный продукт выполняет тестирова-ние во время работы пользователей.

По сути, это уникальная вещь. Пользователи рабо-тают, а в процессе их работы выполняется тестирова-ние, и автоматически протоколируются все ошибки. При этом пользователь даже не увидит того, что про-изошла ошибка.

В момент возникновения ошибки у администратора информационной базы или программиста в списке оши-бок возникает запись: он видит, у какого пользователя, в каком объекте при каких действиях произошла ошиб-ка. И в этом же режиме он может эту ошибку исправить.

Приведу простой пример, пользователь в процессе работы попытался нажать кнопку. В результате, про-изошла ошибка. Пользователю выдается сообщение: «Извините, пока данный функционал не доступен». Программист или администратор увидел ошибку, ис-правляет ее, при этом не требуется перезапуск инфор-мационной базы, потом посылает сообщение пользо-вателю о том, что функционал стал доступен и можно продолжать работу.

Юнит-тестирование

Unit-тестирование – это очень специфическая вещь. Она меняет идеологию разработки программных про-дуктов.

Мы при разработке собственных программ посто-янно используем технологию «разработка через те-стирование». Почему? Потому что любая модификация программы может привести к ее дальнейшей некор-ректной работе. И чем чаще выполняется юнит-тести-рование, тем проще исправить ошибку и раньше она будет обнаружена.

Ведущие специалисты в области разработки про-граммного обеспечения говорят, что тестирование надо делать ежедневно. То есть, ежедневно надо де-лать сборку программных продуктов и проверять, что ничего не сломалось.

Проверка дистрибутивов

Этот программный продукт основан на программ-ном продукте «Сценарное тестирование на уровне опе-рационной системы». Фактически это большой сцена-рий тестирования, в котором выполняется более 300 различных проверок и операций.

Применение тоже очень специфическое, в основ-ном только для тех, кто занимается тиражировани-ем конфигураций.

Позволяет проверять:• что правильно устанавливается защита, • что правильно устанавливаются драйвера защиты, • что правильно устанавливается обновление, • что можно обновить информационную базу с пре-

дыдущей версией конфигурации,• что файл дистрибутива создан согласно правилам

и регламентам, содержит все необходимые файлы и информацию,

• ряд критичных ошибок времени выполнения кон-фигурации.

Этот программный продукт позволяет автоматиче-ски обнаруживать возможные проблемы при выполне-нии установки дистрибутивов и обновлении типовых конфигураций. Но с точки зрения функционала основ-ное предназначение – это корректность создания новых дистрибутивов.

– 77 –


Рарус. Нагрузочное тестирование

Вероятно, это лучшее решение на рынке по тести-рованию производительности работы с СУБД. Это раз-работка компании «1С-Рарус» (gilev.ru). Она позволяет мониторить и находить узкие места в производитель-ности информационных систем и оборудовании. Также он выдает базовые рекомендации по тому, как решить те или иные проблемы.

Разнообразие ошибок и способы их нахождения

Ошибки – это очень неприятно. Ошибок бывает много. И находить можно практически все. Вопрос в том, регулярно надо тестировать или нерегулярно. И сколько стоит автоматизация тестирования. Напри-мер, сами мы тоже применяем ручное тестирование, но только в специфических случаях.

Некоторые ошибки можно автоматически исправ-лять. А для некоторых ошибок можно автоматически определять причины их возникновения, то есть вы-полнять не только тестирование, но и частично авто-матизировать функции отладки.

Что дает автоматизация?• Первое – это качество. Качество программных

продуктов – это принципиально важный момент. Ведь это удовлетворение пользователей и «сча-стье во всем мире».

• Следующий важнейший пункт – это ускорение тестирования. Как уже говорилось, протестиро-вать УПП вручную – это, в принципе, неразреши-мая задача. А автоматически можно протестиро-вать полностью весь функционал за четыре часа. К тому же автоматизация нам дает преимущество, мы можем запускать тестирование ночью: вечером ушли, утром получили список ошибок. Нет допол-нительных затрат времени.

Выводы:• Для повышения качества и надежности программ-

ного обеспечения нужно применять различные методики

• Использование тестирования снижает затраты на разработку и стоимость владения информацион-ными системами

• Ни один вид тестирования не может гарантиро-вать нахождение всех ошибок, но применение раз-личных методов тестирования позволяет серьезно снизить количество ошибок, которые дойдут до пользователей

• Тестирование можно и нужно автоматизировать и для этого есть большое количество различных инструментов

– 78 –

Альтернативные системы контроля версий и практика применения с 1С

Евгений Сосна Профессиональный разработчик 1С, один из разработчиков скриптов для проекта Снегопат (8.х)

От ведущего: Сейчас мы говорили про тесты, кото-рые покрывают код. И, представим себе, что код растет вертикально и тесты как-то его покрывают – можно считать, что это процесс последовательный. А жизнь у нас многоконтекстная. То есть, код может развиваться, условно, ветвлениями – таким «деревом». И, как только мы начинаем делать продукт, он может ветвиться в раз-ные стороны. И контекст у нас от ветки к ветке с тече-нием времени может переключаться. То есть, я сегодня могу заниматься одной задачей, завтра – другой зада-чей, послезавтра – третьей задачей, четвертой – и они все разноконтекстные. А продукт-то один. И жизнен-ный цикл его – один. Хранилище 1С позволяет фактиче-ски вести только ствол дерева. И тут – все вспоминаем – мы же автоматизируем реальность? И именно поэтому Евгений Сосна нам сегодня расскажет, каким образом с помощью альтернативных систем контроля версий автоматизировать эту реальность многих контекстов, когда сегодня у вас один контекст, а завтра второй.

От докладчика: Я собираюсь рассказать о том, ка-ким образом мы с вами можем использовать для разра-ботки в 1С альтернативное программное обеспечение контроля версий, которое существует сейчас в мире. Если выбирать емкое слово, которое должно отразить доклад, то это, наверное, слово «ветки» – ветвления.

С развитием 8.3 по части полной выгрузки конфи-гурации в файлы у нас с вами появилась возможность использовать мировой опыт программного обеспече-ния по контролю версий (ревизий). Соответственно, можно использовать эту возможность как альтернати-ву хранилищу.

Краткий план доклада

Итак, мой доклад посвящен системам версионного контроля и их практическому применению для работы с 1С.

• Сначала я планирую рассказать про историю раз-вития систем контроля версий. На каком этапе сейчас находимся мы с вами.

• Потом расскажу, какие существуют бесплатные си-стемы контроля ревизий, и постараюсь осветить преимущества, которые они нам могут предоста-вить по сравнению с хранилищем конфигурации

• И, наконец, немножко практики применения аль-тернативных систем контроля версий для раз-работки на 1С в совокупности с использованием возможностей 8.3 (какие есть удобства, какие не-удобства, какие возможности вы можете получить уже сейчас,даже до массового перехода на 8.3).

— Альтернатива хранилищу, позволяющая орга-низовывать «ветвления». Линейная история: простота – не значит удобство.

— Обзор кода – свежий взгляд на «бистро-код». Что же изменилось на последних этапах разра-ботки в модулях?

— Авторство кода. — Ложка дегтя. Рассмотрим те проблемы, кото-

рые на сегодня есть в выгрузке конфигураций и ее использовании для задач версионного кон-троля.

История развития систем контроля версий

Система контроля версий – это система, реги-стрирующая изменения файлов для того, чтобы в дальнейшем была возможность вернуться к опреде-ленным старым версиям этих файлов, посмотреть и проанализировать историю разработки.

Историю развития систем контроля версий можно разбить на несколько этапов:

1. Файловые (локальные) копии

– 79 –

Евгений Сосна Альтернативные системы контроля версий и практика применения с 1С

Изначально для хранения версий использовались обычные локальные копии. То есть, еще дискетки были – уже были локальные копии. Мы с вами до сих пор применяем их для внешних обработок, для файлов, для всего, чего угодно. И все в этом методе хорошо. Един-ственное – данные хранятся неэффективно, файловая система засоряется,и через месяц после того, как вы закончите работать с обработкой, вы вряд ли вспом-ните, что находилось в этой Копии Копии от Копии.

2. Локальные системы контроля версийСоответственно, во всем мире еще где-то в 1985

году тоже подумали, что это неправильно, и сделали локальные базы для хранения версий файлов.

Идея использования локальных баз для хранения версий файлов в следующем. Пусть последняя теку-щая версия у нас лежит в файловой системе, а в базе данных хранится вся история этого файла. Причем основная изюминка этого метода была в добавлении комментария к версии. То есть, история версий вашей обработки в базе данных сохраняется не просто с на-званием «Обработка», а еще и с каким-то комментари-ем о том, какие изменения данных вы зафиксировали. Таким образом, для данных задается своеобразный ин-декс, чтобы человек посмотрел и вспомнил – вот в этой версии решалась определенная задача.

И, в принципе, эти локальные задачи контроля вер-сий на тот момент решало такое программное обеспе-чение, как RCS (RevisionControlSystem). Я его упоми-наю ради исторической справедливости. Потому что использовать подобную систему контроля версий име-ет смысл только тогда, когда для разработки исполь-зуется локальная база. Когда у вас и во всем мире на-чинается командная разработка, эта система контроля версий уже не подходит.

Потому что, если есть какой-то файл, находящийся в командной разработке, вы его изменили, и теперь не-обходимо с другими разработчиками поделиться этой информацией и потом синхронизировать эти данные. В случае ведения истории разработки в RCS выполнить эту задачу затруднительно.

В некоторой степени системы на основе 1С:Доку-ментооборот или БСП с подсистемой версионирования файлов также являются локальными системами кон-троля версий.

3. Централизованные системы контроля версий

Соответственно, появились централизованные си-стемы контроля версий. То есть, у нас появился сер-вер, где находится последняя версия всего дерева проекта, всей разработки. В качестве разработки у нас может быть пользовательская документация, любые файлы, сценарное тестирование, допустим (как толь-ко что говорили) – для него тоже надо хранить версии, чтобы понимать, где новые изменения.

Открытыми системами этого типа являют-ся CVS и SVN. До вчерашнего дня я думал, что CVS (ConcurrentVersionsSystem) уже можно выкинуть на свалку истории, но, оказывается, есть в нем некоторые моменты, которые все-таки до сих пор применимы и в наших сегодняшних жизненных реалиях.

Subversion (SVN– сокращение от названия клиента для командной строки, входящей в состав пакета) – это эволюционное развитие CVS. По сравнению со своим прототипом что-то нашло, а что-то потеряло.

Хранилище 1С тоже является централизованной системой хранения версий. В принципе, в хранилище у нас есть и сервер, и права доступа, и две чашки кофе вы можете успеть выпить, пока захватите рекурсивно весь корень конфигурации, да? А если по http-доступу еще или по tcp – ваше счастье… Придется долго ждать.

Работа централизованных систем версий проста. Для каждого программиста-новичка понятна.

– 80 –


1. Получил из хранилища2. Захватил3. Отредактировал4. Поместил обратно.

Такая простая схема работы сцентрализованными системами быстро завоевала признание людей, так как позволила быстро вникнуть в разработку и получить последнюю версию/копию.

Но у централизованных систем есть и некоторые недостатки:

1. Первый недостаток – это, конечно, то, что сервер фактически является «единой точкой отказа». В связи с этим совет: делайте backup хранилища. На самом деле, хотя бы базы данных. Но хранили-ща тоже, пожалуйста, делайте. Потому что если с сервером что-то случится – восстановиться можно будет только из backup-а.

2. Следующая особенность – пессимистическая блокировка. Некоторые считают, что, когда в цен-трализованной системе разработчик захватывает объект, он,таким образом, всем объявляет свое намерение, что собирается в этом объекте что-то изменить. К тому же, многие руководители дума-ют, что они, таким образом, контролируют этого разработчика. То есть, раз разработчик захватил какой-то там документ – значит, мы знаем, что он над ним работает, и он его к какому-то периоду времени сделает. По факту, если это уже опытный специалист, и вы ему доверяете, то он,конечно, всегда обоснует, почему он месяц назад объект захватил и до сих пор не поместил его в хранили-ще. Но, все равно – эта пессимистическая блоки-ровка накладывает на нас ограничение, кото-рого можно было бы избежать. В дальнейшем в распределенных системах обошли этот путь. Также, если у вас идет глобальный рефакторинг, или идет какое-то исправление модуля и срочно необходимо исправить ошибку – тоже может воз-никнуть проблема. В худшем случае – база сто-ит, ничего не работает. В лучшем – возникает дилемма, 50% кода уже исправлена, то ли поме-щать в хранилище неоттестированный код, то ли сохранять его куда-то в файл. И у нас опять появ-ляется в файловой системе «Копия конфигурации такой-то» и мы забыли/не забыли ее вернуть об-ратно в конфигурацию.

3. И есть еще в централизованных системах такое со-глашение – это за или против, я даже сомневаюсь – что последняя версия у нас самая оттестирован-ная и самая рабочая. По факту, наверное, так и есть. Но только если мы тестируем на пользователях. То есть, нам сказали, что есть ошибки, мы их испра-вили и только тогда положили объект в хранили-ще. Только в этом случае мы можем быть уверены, что в хранилище у нас более-менее рабочая копия. В любых других случаях – для простого програм-миста у нас тестов нет (мы это поняли по преды-

дущему выступлению). Разработчики типовых конфигураций не покрывают код тестами. То есть, дописал свое, запустил полное тестирование, проверил, как работает – такого нет. Будет ли? Время покажет.

4. Распределенные системы контроля версий

Следующим этапом развития систем контроля вер-сий стали, конечно же, распределенные системы. Ос-новная идея этих распределенных систем контроля ревизий – это ветвление.

Ветвления – это некие параллельные процессы, когда есть один родитель, и две истории от него отпоч-ковываются. Самое хорошее у них то, что с помощью одного этого родителя вы в дальнейшем можете объ-единить эти истории.

Условный такой пример ветвления, который все знают, это конфигурация на поставке. Файл обновле-ний является «патчем» для конфигурации поставщика. При обновлении конфигурации поставщика на ее осно-ве воссоздается новая конфигурация поставщика, ко-торую вы не видите, но она есть. И, запустив действие «Показать дважды измененные», вы можете увидеть упрощенный вариант «трехстороннего сравнения». То есть, можно сказать так: в конфигураторе «трехсто-роннее сравнение» есть, но оно скрыто от разработ-чика. Те, у кого есть «Снегопат», могут что-то в этой ситуации подкорректировать и все-таки посмотреть трехстороннее сравнение. Но от остальной массы раз-

– 81 –


работчиков трехстороннее сравнение в конфигураторе скрыто.

Преимущество распределенных систем в том, что у них нет единого сервера, и каждая копия хранили-ща может в любой момент выступить в качестве сер-вера. Но за эту особенность нам приходится платить местом на жестком диске. Это, конечно,проблема. Но, учитывая современные возможности и небольшую стоимость соответствующего оборудования – эта про-блема незначительная. Сами распределенные системы поддерживают режим работы как в серверном режиме (как централизованные системы контроля версий), так и в децентрализованном режиме. Причем, согласно моему практическому опыту, для распределенных си-стем сервер все-таки нужен.

Ключевые особенности

Итак – что отличает распределенные системы кон-троля версий от всех остальных?

• Во-первых, как только перед вами встанет задача с кем-то обменяться информацией – для вас станет необходимостью организовать какой-то сервер. Пускай он будет развернут даже на вашей локаль-ной машине, но для обмена сервер необходим.

• Во-вторых, по сравнению с централизованными системами, где обычно можно было бы на опреде-ленные объекты поставить ограничение доступа,в распределенных системах нет смысла говорить о какой-то блокировке на определенный файл. В централизованной системе, например, в храни-лище, у нас есть возможность на определенные объекты поставить доступ на чтение/запись, а в распределенной системе, поскольку вся копия проекта копируется разработчику на машину – разработчик все равно может этот файл изменить, прочитать и т.д. Это, наверное, одна из проблем…Но при желании, если вам необходимо какому-то удаленному разработчику выгрузить определен-ную подсистему, чтобы он ваше основное дерево конфигурации не смотрел, вы можете выделить эту подсистему в отдельную конфигурацию. Спосо-бы решения есть. Например, можно какую-то часть дерева истории выгрузить, а потом обратно загру-зить уже изменения, которые разработчик внес.

• Еще один важный момент, о котором я говорил: в централизованных системах на сервере должен всегда быть оттестированный код. В децентра-лизованных системах, когда вечером вы уходите домой, вы можете спокойно поместить в свою локальную копию неработающий код. Поверьте, это очень удобно, когда поместили свои изменения и записали для них какой-то естественный ком-ментарий. От комментария многое зависит. Если вы с пустым комментарием что-то помещаете в то же хранилище, то я бы это не приветствовал. По-нятно, что вы тут что-то изменили… А что по фак-ту? С учетом скорости хранилища это практически невозможно узнать.

• Ветвление, естественно, является палкой о двух концах. Оно, как линия жизни вашего проекта,мо-жет уйти куда-то в сторону, а может держаться ге-неральной линии. Это надо прочувствовать на себе. И основной принцип – ветвиться часто, но в меру.

Режимы работы распределенных систем

Распределенные системы поддерживают различ-ные режимы работы.

• Если вы разворачиваете проект для одного себя, вы можете использовать базу хранения версий локально.

• Можно по старинке – с центральным сервером. Причем вы можете копировать не полностью весь репозиторий на него, а только нужные вам для хранения истории файлы. Допустим, выгрузка хранилища 8.3 занимает 1.5 Гб. Разработчику пер-вый раз выгрузить содержимое репозитория по ка-налу интернета очень тяжело. В то же время, можно выкачать только последние изменения, с которыми он работает. Так, поддерживается тот же принцип централизованной системы, как и в хранилище.

• Без центрального сервера тоже можно работать. Но, в любом случае, какой-то сервер, хотя бы на ло-кальной машине, организовывать все равно нужно.

• И наконец, самый предпочтительный и самый удобный способ – с центральным сервером, с ло-кальными фиксациями и ветками. Однако на-стройка будет наиболее трудоемкой.

– 82 –


Какие есть системы?

Альтернативы достаточно разнообразны:

Я специально выделил Mercurial – потому что, к со-жалению, если брать практику разработки хранения версий именно для 1С – эта распределенная система не подходит. У нее есть проблемы с кодировками в наиме-нованиях файлов и, когда перед вами встанет вопрос об осуществлении обмена с другим сервером (напри-мер, один сервер будет базироваться на ОС Windows 7, а другой – на WindowsXP), вы не сможете синхрони-зировать данные из-за различного представления ко-дировок имен файлов для различных ОС. То есть, к со-жалению, его нельзя пока использовать. Хотя это моя любимая система, т.к. она более логичная и с ветками работает наиболее понятно. Особенно для новичка, делающего попытки разобраться в принципах работы.

SCM fossil

Также отдельно хотелось бы выделить распреде-ленную систему SCMfossil. С этой системой контроля версий я познакомился, когда познакомился со Снего-патом.

Ее особенности:• Проста• Удобна• Весь пакет инсталляции содержит один файл exe,

который содержит в себе — Систему версионного контроля — Систему документирования на основе wiki

— Простейший баг-трекинг — Встроенный web-сервер

• Управляется с web-браузера• Единственный недостаток – нет GUI-интерфейса,

к которому все привыкли. То есть,мышкой покли-кать, чтобы сделать коммит/добавить файл – не получится. Посмотреть изменения через web-ин-терфейс можно. Но все остальное стандартно, только через консоль

• Советую применять для внешних обработок, от-четов, схем СКД,различных внешних файлов. Почему-то у нас не любят хранить версии схем СКД, но ведь в процессе разработки схемы для ка-кого-то отчета можно уйти в сторону и потом не вспомнить, какую схему мы использовали изна-чально…

• Также SCMfossil можно применять как замену хранилищу для удаленной разработки или для малой разработки. Например, если у вас неболь-шая конфигурация или раз в два месяца какая-то удаленная разработка – чтобы вспомнить, что же там было в изменениях, fossil подходит просто иде-ально. Компактный и поддерживает все необходи-мое для удобной работы.

Здесь приведен простой скриншот web-интерфей-са fossil с реальной работы. Внизу видно, как какая-то

ветка разработчика слилась в основной ствол дерева.

Практика применения

– 83 –


Теперь продолжим про практику применения в 8.3 различных распределенных систем.

В ходе экспериментов с различным программным обеспечением я для себя составил такой набор необхо-димых инструментов:

• Система управления задачами – Redmine. Я ис-пользую ее совместно с удобным плагином для обзора кода CodeReview

• Сервером для Git у меня служит такая программка, написанная на Java, как Scm-Manager,– контроль репозиториев. Удобно ставится, настраивается че-рез простейший web-интерфейс – запустили, и все работает.

• TortoiseGit – клиент для Git под Windows на осно-ве «черепахи». Кто работал с Subversion – тот знает, что есть такой TortoiseSVN, TortoiseGIT и пр.

• И главный виновник торжества – 1С:Предприя-тие 8.3. Это то, что нам позволяет полностью вы-грузить конфигурацию в файловую систему.

Связь коммита с задачей

Рассмотрим простейшие понятия. Может, это даже

больше относится к системам управления требований (задач).

У меня есть настроенная синхронизация хранили-ща 1С:Предприятия с GIT, и, в дальнейшем, это переда-ется уже в систему управления задач Redmine.

Соответственно, когда мы помещаем данные в хра-нилище, нам интересно видеть в системе управления задач те изменения кода, которые у вас образовались для решения данной задачи.

Соответственно, сама идея связывания таких за-дач проста и используется во всех системах багтре-кинга: вы в комментарии к так называемому коммиту пишете определенное ключевое слово и номер зада-чи, которая закрывается с помощью этого коммита.

Есть плагин для Снегопата, который позволяет при помещении объекта в хранилище подключиться к Редмайну, выбрать определенную задачу, связанную

с этим объектом, и автоматически сформировать краткое содержание того коммита, который должен быть (чтобы вы руками эти данные не писали). Со-ответственно, если нет Снегопата, то эти действия нужно делать руками. Хотя бы просто указать, какая задача закрылась.

В результате для задачи в системе Редмайн в поле «Связанные редакции» вы получите такую картинку –

можно перейти, посмотреть, какой код изменялся. Это очень удобно.

Ветвление

Эта тема очень большая и актуальная.

Самих способов ветвления три. Остальное – их ком-бинации.

• Ветвление по функционалу.

Например, вы разрабатываете какую-то подсистему – она разрабатывается неделю-две. И, в то же время, она еще окончательно не готова (не работает пока). Сейчас у вас какая задача:

— захватить корень, — добавить новый объект — отпустить корень — Работать над объектом — Если он кому-то понадобится – отпустить

– 84 –


— Потом опять захватить и т. д.

В результате,линейная история просто превра-щается в кашу. Вы уже не знаете, где у вас новая функциональность, где исправление ошибок,а где была сделана просто текущая работа. Не дай бог надо откатиться на предыдущую версию какого-то одного объекта, для этого придется откатиться на пять версий назад. И тут оказывается, что там уже какие-то зависимости в ролях прописаны, какая-то новая подсистема за это время была добавлена… Так просто для хранилища откатиться почему-то не получается.

Соответственно, что такое ветвление по функцио-налу различных доработок, подсистем? Вы выде-ляете ветку под какую-то подсистему, туда про-изводятся коммиты, изменения… И когда она у вас уже готова – делаете так называемый «мерж» (объединение историй). То есть, опять-таки, за счет общего родителя (на картинке представлен пример – я думаю, понятно, что разработка нача-лась с определенной версии), после какого-то про-межутка в несколько коммитов изменения были влиты в основной ствол разработки. И это одно из преимуществ ветвлений, которое просто завоевы-вает мир, позволяя вот так непринужденно ветвить вашу историю, давая разработчику возможность разобраться, как же оно получилось.

• Следующий способ ветвления – ветвление по пользователям. Тоже применяется. Например, у вас есть удаленный разработчик, или какой-то новый молодой специалист. И у вас стоит ком-промисс – или дать доступ на запись в хранилище или… По мне, так это – «пусти козла в огород»… Если не проконтролировать, что он там изменял, завтра с базой будет совсем плохо. Одно дело, если этот «специалист» рядом сидит, и его проконтро-лировать и сделать ему какие-то замечания не со-ставляет труда. А если это удаленный разработчик и он уехал куда-то в Таиланд – то… хранилище не поможет вам этого разработчика проконтролиро-вать. Только если дать ему конфигурацию храни-лища на чтение, а потом вам или ему мучиться с объединением. Никто не захочет дальше работать с вами. А возможность использовать трехсторон-нее сравнение позволяет определить именно те объекты, которые были дважды изменены, и быстро, с помощью различных инструментов типа kdiff3, их объединить. Это дорогого стоит.

• Ну и самый последний, не любимый мною способ ветвления, – это ветвление по задачам. На каждую задачу открывается отдельная ветка. Потом – вы задачу решаете, ветку закрываете. Поверьте, если задача у вас не долгоиграющая, и она закрывает-ся за один-два коммита – лучше отдельную ветку под нее не выделять, потому что в определен-ном смысле вы можете уйти совершенно в другую

степь. В этом смысле ветвление – это «зло». Может вдруг оказаться, что в ветке, предназначенной для решения одной задачи – вы «на автомате» начнете реализовывать и другие задачи, для других подси-стем, и в один момент времени может оказаться, что ваша основная ветка стала называться не trunk, а «суперРазработка252». Разобраться, где что, бу-дет уже сложнее.

Обзор кода

На прошлой конференции Артур Аюханов говорил, что одним из методов повышения качества кода явля-ется обзор кода. Если быть честным – в хранилище обзор кода мы сделать не можем. То есть, согласно модели работы, когда у вас база подключена к хранили-щу, вы не знаете, какая версия у вас в принципе сейчас есть в хранилище. Безусловно, действием «Обновить конфигурацию из хранилища» вы можете получить к себе на компьютер последние изменения. Но, по факту, часто разработчики захватывают только те объекты, с которыми им нужно работать, и в результате может получиться какая-то сборная солянка.

Конечно, это решается административным путем. То есть, пришел утром на работу, сделай обновление конфигурации из хранилища. Посмотрел, что у тебя в хранилище 10 объектов измененных, смотришь «А кто их изменял?». Если там два программиста – еще можешь спросить/узнать, что же там изменяли. А если больше двух? Здесь начинается проблема коммуника-ций, и понять – кто же что изменял в хранилище, до-вольно-таки трудно.

Соответственно – обзор кода нам позволяет за-ставить себя исправить наш «бистро-код». То есть, вы быстро его сделали, забыли, потом посмотрели. В Редмайне это позволяет вам, если что-то не нравит-ся,встать на ту строчку кода, которая вам не нра-вится, нажать «Создать задачу»и назначить ответ-ственным за эту задачу того, кто поместил этот код в хранилище. Эта задача висит над ним, как «дамоклов меч». Она, конечно, может висеть долго-долго, а может сразу исправляться.

Удобство такого представления информации в со-вокупности с одновременной установкой задачи очень

– 85 –


помогает рассмотреть те изменения, которые были сделаны в вашем хранилище или в альтернативном репозитории.

Авторство кода

Самая интересная картинка – «Авторство кода».

В хранилище я пока не знаю, как получить «Кто же писал эти строки?»

И, если разбираться, где там закралась ошибка, то, используя метод бинарного поиска, пять минут на по-лучение из хранилища cf-ника – узнаем, что все-таки оно не здесь изменилось, и так дальше-дальше-дальше – пытаемся найти, кто же когда это изменил.

А тут, с помощью любого редактора, поддержива-ющего вывод авторства строк (того же GIT), вы може-те встать на определенную строчку кода, и он вам покажет ту версию, с которой это было изменено. А потом еще дополнительно покажет все версии этого файла, которые были в системе контроля версий.

Думаю, многие с этим встречались, и кто-то может сказать, что все равно неизвестно, кто виноват (один программист одно условие добавил, а кто-то выше до-бавил еще какое-то условие – это он виноват).

Я еще понимаю, если бы нам приходилось получать подобную информацию из хранилища – можно было бы сказать, что нам и такое не нужно, но… я убежден, что такое представление информации очень помогает найти многие ошибки, найти ответственного за подоб-ные исправления в коде.

Практика применения при выгрузке конфигурации в 8.3

Ложка дегтя

Сразу скажу, просто так взять и использовать вы-грузку у вас не получится.

• Во-первых, ваша древовидная конфигурация пре-вращается в файловой системе в линейный список. То есть, например, наиболее распространенная конфигурация УТ10.3, в разобранном виде пре-вращается в 9451файл в одной папочке. Причем, ориентироваться по таким файлам просто невоз-можно (Документ.Реализация.МодульОбъекта.txt). С учетом того, что по алфавиту там сначала идут роли, найти в этом списке нужный объект очень затруднительно.

— Соответственно, для этого я использую такой метод – я выгружаю файл конфигурации в от-дельную папку, а потом из этой папки копирую файлы в хранилище GIT с учетом структуры каталогов. То есть эта структура повторяет то же дерево, которое у нас есть в конфигурации. Для этого у меня есть специальная обработ-ка, которая по точке, методом «МассивРазло-житьВСтроку» разносит файлы по каталогам. Это позволяет наглядно посмотреть. Опять-та-ки, нам в скором времени обещают в 8.3 ускоре-ние работы с хранилищем, но, в принципе, при такой выгрузке с помощью GIT все равно то же самое получается. Вы получаете ту же самую информацию – только быстро, удобно… даже при ее линейном формате. Так же, как это в хра-нилище и есть.

• Еще немаловажный факт – обычные формы вы-гружаются во внутреннем формате. То есть, файл форм «закодирован» во внутренний формат 1С. Почему так сделано, мне, если честно, непонятно, так как в 8.2, допустим, у нас есть возможность по-лучить модуль формы. Еще раз уточню: это касает-ся только «толстых» форм. Я понимаю, что управ-ляемые формы «побеждают весь мир», но УПП 2.0 еще не вышло, а у нас еще есть УПП1.3, которое еще на «толстых» формах – живет и здравствует.

— для этого есть обходные пути – есть такая

– 86 –


чудная программа V8Unpack, которая распа-ковывает эти формы на внутреннее пред-ставление формы и на модуль формы. Соот-ветственно, эта проблема просто обходится.

• Огромный объем выгрузки ролей в файлы. — для меня стало неожиданностью, когда я уви-

дел, что, оказывается, роли выгружаются полностью, то есть, есть возможность указать для роли «Право по умолчанию» на объекты. Но, все равно, роли выгружаются полностью. И, соответственно, есть проблема в хранилище. У вас, допустим, роль не захвачена, и в то же время вы добавили какой-то реквизит в доку-мент. Вроде как только изменения документа идут, да? Если вы сделаете выгрузку конфигу-рации в XML, то у вас окажется, что у всех ро-лей есть изменения – добавлено новое право на новый реквизит (явное разрешение на чтение этого реквизита). Подчеркну, в выгрузке XML – изменение во всех ролях!!

— Кроме этого, есть еще проблема, связанная с тем, что роли из всего каталога конфигурации занимают наибольший размер.

• И, конечно же, нет выборочной выгрузки/за-грузки. Я не говорю даже о скорости загрузки/выгрузки. Но, хотя бы выборочно выгружать, что-бы как раньше – можно было частично выбирать – выгрузить только документы или определенные документы. У нас бы стало проще с работой, не так долго нам пришлось бы выгружать/загружать эти данные, мы могли бы быстрее получать готовый результат.

Порядок выгрузки

Если судить по опыту, я взял хранилище на 8.2 (там история разработки более 500 ревизий).

• В этом хранилище я брал каждую версию и вы-гружал ее в cf-файл,

• Потом загружал в 8.3,• И, наконец, выгружал в файловую структуру.

Таким образом, я смог сконвертировать хранилище 1С в альтернативную систему контроля версий. Конеч-но же – больше всего времени заняла выгрузка в 8.3 в файлы. И еще создание конфигурации из версии хра-нилища.

На этой картинке я показал пример разбивки по документам (по файловой структуре). Я думаю, здесь просто и понятно, что как изменялось.

Выводы

Соответственно, краткие выводы:

1. Как альтернатива, вы можете использовать сей-час и GIT, и SVN, и BZR, и fossil – это все поддер-живаемые системы. Если говорить про какую-то интеграцию с системой баг-трекинга, то здесь побеждает SVN и GIT. Если вы еще захотите вет-вления – то, конечно же, без альтернативы GIT. То есть, вроде как у вас есть альтернатива – но, тем не менее, альтернативы нет.

2. Синхронизация хранилища 1С с git работает.3. Ветвление, в принципе,работает.4. Единственный минус – просто так взять и вос-

пользоваться в этом плане 8.3, к сожалению, нет возможности, то есть, без доработок не обой-тись.

Еще что хотелось бы сказать по поводу версионно-го контроля.

Я считаю, что работа с системами версионного контроля – это наше будущее. И, в принципе, хотелось бы, чтобы у нас все-таки или развивалось хранилище в этом плане, или инструменты по выгрузке/загрузке данных были более удобными для разработчика.

– 87 –

Новые возможности платформы «1С:Предприятие 8.3»

Андрей Аристархов1С, Представитель отделения разработки фирмы “1С”. Руководитель направления «Иннова-ции и интегрированные решения»

Здравствуйте! Инфостарт разрешил – мы решили выступить. Доклад несколько необычен, потому что мы решили сделать небольшое исключение и расска-зать о новых возможностях платформы до того, как она выходит. Обычно мы это делаем на партнерских семинарах. Мы решили рассказать это здесь. Сегодня вы услышите то, что раньше никогда не слышали.

Информации, конечно, будет поменьше, чем на партнерском семинаре, просто в силу ограничений по времени. Но, что хочется донести: я постараюсь расска-зать, почему мы делаем то или иное и откуда идут на-правления развития платформы.

Развитие и продвижение программных продуктов фирмы 1С.

Статистика

Вначале посмотрите, как мы все вместе хорошо ра-ботаем.

В 2011 году 1С был единственным вендором в сег-менте ERP систем, который увеличивал свою долю рынка.

Если в 2010 его доля была 26%, то в 2011 – она уже 31,6%.

С нетерпением ждем результатов 2012 года. Дей-ствительно, очень интересно. Причем, эти диаграммы представлены в денежном выражении. В количествен-ном выражении – на следующих слайдах.

Я был на первом InfostartEvent. Видел, как люди от-носятся к платформе. Я уверен, что у людей, которые здесь собрались, нет вопроса – что использовать для автоматизации предприятия.

Спасибо вам за то, что вы делаете, спасибо за то, как вы автоматизируете. Цифры IDC говорят сами за себя.

А мы, в свою очередь, стараемся сделать все, чтобы вы могли это делать более эффективно.

На этом слайде представлена информация с сайта 1С. Она публично доступна. Есть монитор продаж/вне-дрений УПП. Небольшие цифры, можете посмотреть. Это данные на конец апреля.

73 внедрения ERP-систем за месяц – хороший ре-зультат.

– 88 –


КАМАЗ. Да, что там делают 7000 человек – на КАМА-Зе? Не поверите – работают. Причем, работают очень эффективно. Да, естественно, это внедрение в группе компаний, но это – единая система, где увязано более 7000 человек.

Этапы развития платформы 1С:Предприятие

А теперь – по развитию платформы.

Сейчас параллельно поддерживаются и развивают-ся две ветки – текущий релиз ветки 8.2 – 8.2.18 (уже вышла), 8.3.3 – выходит.

В какой-то момент, естественно, развитие ветки 8.2 будет остановлено. Будет развиваться только ветка 8.3.

Новые возможности 8.3. Основные направления

Развивая 8.2, мы постепенно двигались в сторону облачных направлений, добавляли какой-то новый функционал, например,multitenancy. Это были такие отдельные «пробы пера» – технологические новинки в области облачных технологий.

Теперь, в версии 8.3, мы сформировали уже целый комплекс, который, на самом деле, является одним из основных драйверов развития платформы.

• Это сложные системы• Это облачные системы, потому что облачная ин-

сталляция по технологическим свойствам сравни-ма с инсталляцией для большого количества одно-временно работающих пользователей.

• Linux – скажите, кто рад тому, что 1С полностью работает на Linux? Вот видите, как много радости мы вам принесли с новой версией!

• Кому интересна мобильная платформа? Еще больше – супер!

• Важный момент – он, буквально, отражен одной строчкой. С 8.3 можно будет в любой момент откатиться на 8.2 без изменений и без танцев с бубнами. Просто взять и поменять платформу 8.3 на платформу 8.2, если вдруг что-то не заработа-ет. Это задача совместимости очень серьезно у нас развивается. И, в рамках 8.3 нам удалось достичь достаточно серьезных возможностей по режимам совместимости.

Облачная платформа 1cFresh

– 89 –

Андрей Аристархов Новые возможности платформы «1С:Предприятие 8.3»

На этом слайде представлена эталонная архитекту-ра облачных вычислений от компании IBM – публичная спецификация, которая является результатом система-тизации знаний по облачным решениям от этой ком-пании. Здесь достаточно хорошо все детализировано.

Одним из основных элементов в облачных архи-тектурах является платформа управления, то есть то, что решает задачи управления – единое управле-ние пользователями, биллинг и т.д. Извините, что на английском, просто не очень удобно было переводить, потому что это единая картинка.

Кто слышал про технологию 1сFresh? На самом деле, 1сFresh – это платформа управления облач-ными услугами. В рамках разработки этой платфор-мы мы частично реализовали тот комплекс сервисов, который представлен квадратиками на этой картинке, естественно, снабдив его соответствующим набором программных интерфейсов.

Вообще, у разных вендоров для закрытия различ-ных сервисов используются различные программные продукты или наборы программных продуктов, инте-грированных между собой. У нас это все сделано вот так:

Мы старались как можно больше упростить за-дачу создания облачных услуг – для корпораций, для провайдеров. А для того, чтобы им не приходилось повышать свои знания в области каких-то других про-граммных продуктов – мы все это сделали в рамках технологии 1сFresh.

Причем, элементы облачной архитектуры реали-зованы не только в рамках прикладных решений «Ме-неджер сервиса» или «Агент сервиса», они также за-трагивают «Библиотеку стандартных подсистем» (для работы необходима внедренная подсистема «Работа в модели сервиса» из БСП). К тому же, некоторые механизмы заложены в платформу(тот же механизм multitenancy – заложен в платформе).

Есть два продукта – технология разработки ре-шений 1сFresh и технология публикации решений 1сFresh. Чем они отличаются?

Технология разработки – это методология разра-ботки приложений. Это те компоненты, которые по-зволяют вам разрабатывать, отлаживать и тестиро-вать приложение при работе в модели сервиса.

• Менеджер сервиса• Агент сервиса

– 90 –


• Демонстрационное приложение «Работа в модели сервиса»

Технология публикации – это набор продуктов, который позволяет развернуть свой собственный об-лачный сервис. Обеспечивает интеграцию с web.

Что было важно:• Мы сохранили ту же самую модель разработки

приложений.• Если посмотреть на методологию, код надо ме-

нять совсем немного. Есть несколько моментов, которые отражены в данной методологии, где не-обходимо менять код. Менять его надо просто с учетом того, чтобы приложение одновременно могло работать и в коробочном варианте (кли-ент-серверном) и в облачной модели. На самом деле, платформа достаточно уникальна. Вы пред-ставляете себе – desktop-приложение, клиент-сер-верное приложение, облачное приложение… И все это – один и тот же код.

• Можно брать существующие прикладные реше-ния, реализованные на 1С, а не набор различных продуктов – это касается наших корпоративных клиентов – и разворачивать их в облаке, исполь-зуя платформу 1С.

• Причем, естественно, у нас есть свои собственные интерфейсы для управления облаком. Как прави-ло, в корпорациях, где облачные технологии, так

или иначе, уже используются, и можно совершен-но спокойно интегрировать 1сFresh в уже суще-ствующее общее облачное пространство. Для этого соответствующие инструменты и интер-фейсы есть.

• Механизм разделения данных позволяет решить задачу управления НСИ (нормативно-справочной информацией) – эта задача особенно актуальна в рамках больших холдингов, когда существует один экземпляр справочника на все организации, та-кие неразделенные данные, которые используют пользователи в разделенном режиме

• Возможность быстрой разработки и старта «с нуля» небольших облачных решений. Быстрота разработки на платформе вам хорошо известна. Теперь можно и облачные решения быстро раз-ворачивать.

• Готовое решение для «облака» мобильных або-нентов. Вообще – это два основных технологиче-ских тренда: облачное направление и мобильное направление. То есть, они так «двигают». Причем, они взаимосвязаны. Потому что – если у вас есть мобильное устройство, то вам нужно где-то хра-нить информацию. А где? У кого iPhone – хранит информацию в iCloud – в «облаках». То есть, «обла-ка» и «мобильное» – тесно вместе связано.

Вот таким вот образом устроен наш сервис – 1cfresh.com

– 91 –


Мы являемся поставщиком услуги. И, соответствен-но – ежедневно, ежечасно на себе ощущаем, что проис-ходит, когда эксплуатируется такой сервис.

Ну, я уже вкратце объяснил, что это очень эффек-тивное решение для холдингов. Потому что ведет к снижению затрат. Конечно, возможность централи-зации инфраструктуры с помощью этой техноло-гии во многом определяется качеством каналов связи. Но тем, кто может организовать качественную связь в рамках подобного проекта централизации,технология позволяет значительно сэкономить средства.

Здесь представлен перечень технологических функций, которые реализованы в сервисе 1cfresh.com. Вы уже видели их – в виде квадратиков при пока-зе инфраструктуры облачного решения.

• Взаимодействие партнеров и клиентов (актуально для провайдеров)

• Мониторинг работоспособности компонент сервиса и оповещение администраторов

• Информирование о запланированных и незапла-нированных простоях

• Единая аутентификация (OpenID)• Автоматическое обновление версий приложе-

ний• Автоматическое обновление нормативно-спра-

вочной информации

• Переход из локальной версии в сервис и обратно• Персональные резервные копии• Обмен данными между приложениями абонента

в сервисе• Обмен данными между приложениями сервиса и

локальными приложениями• Интеграция между приложениями и системой

сдачи отчетности• Доступ к методическим информационным ре-

сурсам• Автоматический сбор статистики по работе сер-

виса• Другие возможности

Технологии разработки решений для сервиса 1cfresh.com отрабатываются нами, фактически, на себе, и мы делаем эти технологии тиражными для того, чтобы вы могли их применять для решения своих задач.

Особенности разработки прикладных решений для использования их в модели сервиса

• Требуется внедренное БСП. — С подсистемой «Работа в модели сервиса».

Там как раз реализован некоторый слой аб-стракции, который позволяет вам не думать о том, в какой модели работает приложение – в локальной модели или в модели сервиса.

– 92 –


— Описано в руководстве по технологии разра-ботки 1cFresh

• Очень важно то, что качество решений, которые разворачиваются в «облаке», должно быть зна-чительно выше. Потому что, если у вас работает 20 человек – это одна нагрузка. Но когда у вас ра-ботает 100 компаний, 100 подразделений по 20 человек –это уже совершенно другая нагрузка. По-этому я говорю о том, что облачная инсталляция сравнима с большим корпоративным внедрением. То есть, решение должно быть

— Более производительным — Менее ресурсоемким — Более надежным и корректным

• Большая часть вопросов разработки актуальна для любых клиент-серверных решений, особенно с высокой нагрузкой.

Развитие кластера серверов 1С

Под воздействием улучшенных технологий прои-зошло развитие архитектуры управления кластером серверов.

Произошла значительная модернизация по направ-лениям:

• Упрощение администрирования• Повышение масштабируемости и надежности• Возможность гибкой настройки кластера для

сложных систем. Что-то настраивается автомати-чески. А что-то мы можем настроить вручную

• Поддержка использования кластера в режиме сервиса.

Для упрощения администрирования были про-изведены следующие улучшения:

• Реализована новая архитектура балансировки нагрузки кластера серверов

— Администратор определяет состав компьюте-ров (рабочих серверов), на которых размеща-ется кластер

— Может определить «требования» к ним: ка-кие сервисы и соединения с информацион-ными базами должны работать на каждом из рабочих серверов

— Менеджеры кластера и рабочие процессы за-пускаются автоматически, исходя из назначен-ных «требований»

— «требования» к рабочим серверам могут быть заданы:• интерактивно, из консоли администриро-

вания кластера, • или программно, из встроенного языка

• Развитие средств администрирования кластера серверов

— Сервер администрирования (RAS) — Утилита командной строки позволяет адми-

нистрировать все. То есть,функции админи-стрирования теперь стали доступны, в том чис-ле и из кода 1С.

— JAVAAPI. Появление JAVAAPI произошло по при-чине того, что платформа 1С стала полностью кроссплатформенной, то есть появилась под-держка Linux. Поэтому – должен был появиться некоторый универсальный интерфейс – он был реализован в виде JAVAAPI.

• В составе кластера реализованы два новых серви-са

— Сервис лицензирования – виртуализация сер-верных ресурсов. Мы надеемся, что его появ-ление в значительной степени решит пробле-му развертывания платформы в виртуальной среде. То есть, вы можете сервис лицензиро-вания назначить на определенную машину в рамках кластера, и все сервера, где есть рабо-чие процессы, клиенты, будут обращаться к этому сервису и забирать лицензию оттуда. Достаточно зафиксировать одну только ма-шину, чтобы не изменялась конфигурация. Все остальные пользователи системы могут ми-грировать, перемещаться – использовать все те технологии обеспечения отказоустойчивости, которые предоставляют виртуальные среды.

— Сервис внешнего управления сеансами по-зволяет управлять пользователями при под-ключении. Этот сервис необходим для облач-ных систем, для корпоративных систем. То есть, перед входом в систему, можно назначить сервис, который проверяет, доступна ли этому пользователю определенная услуга. Появля-

– 93 –


ется возможность более тесной интеграции с существующей корпоративной облачной средой.

Возможности настройки кластера серверов 1С были расширены по следующим направлениям:

• Автоматическая балансировка. То, о чем я гово-рил. Балансировка сейчас настраивается проще, то есть – вы задаете уровень отказоустойчивости, а количество рабочих процессов, которые необхо-димо поднять, количество процессов менеджеров кластера – это все новый кластер делает автома-тически.

— Автоматическое распределение рабочих про-цессов по серверам кластера

— Автоматическое распределение сервисов и се-ансов по серверам кластера

— Автоматическое распределение соединений пользователей по серверам кластера

— Анализируется время реакции, количество со-единений с рабочим процессов, количество ИБ на рабочем процессе

• Ручная настройка. — Настройка места выполнения сервисов и сеан-

сов ИБ — Запрет выполнения сервиса на конкретном

сервере — Настройка количества ИБ и соединений на

один рабочий процесс — «Тонкое» управление параметрами использова-

ния оперативной памяти – можно выставлять ограничения: сколько памяти может быть ис-пользовано за один вызов и вообще – сколько памяти может использовать конкретный рабо-чий процесс.

• Возможность более тонкой настройки вруч-ную позволяет для сервиса ИБ назначить конкретное место выполнения – чтобы он вы-полнялся на конкретном узле. Например, ин-дексирование для полнотекстового поиска что-бы выполнялось на более мощной машине (на отдельном сервере).

Дополнительные настройки кластера• Распределение нагрузки в кластере. Тоже можно

задавать различные политики распределения на-грузки.

— Приоритет по производительности — Приоритет по памяти. Например, если есть

приоритет по памяти, то кластер работает та-ким образом, чтобы снизить потребление ре-сурсов, то есть, например, все сессии одной ин-формационной базы постепенно мигрируют на один рабочий процесс, чтобы не было дополни-тельных затрат на использование памяти. • Может использоваться при обслуживании

кластером большого количества информаци-онных баз с невысокой нагрузкой на каждую

• Приоритет требований назначения функцио-нальности. Это тоже достаточно гибкий механизм, который позволяет вам оптимизировать работу вашей инфраструктуры именно так, как вы хотите, с тем, чтобы оптимально балансировать нагрузку, использовать ресурсы и т.д.

— Позволяет гибко настроить перераспределе-ние функциональности между серверами, вхо-дящими в кластер, при выходе из строя части серверов

— Требования с меньшим приоритетом применя-ются при невозможности следовать требова-ниям с большим приоритетом.

– 94 –


Особенности использования кластеров в качестве сервиса.

• Пользователи кластера относятся к разным ор-ганизациям (абонентам) и используют изолиро-ванные друг от друга множества данных. Раз-личные сценарии использования:

— Несколько абонентов в одной информаци-онной базе с типовой конфигурацией• Механизм разделения данных – тоже очень

интересная вещь. Ведь, когда в облаке раз-вернута одна информационная база, и там работают несколько компаний, независимо друг от друга, нужно гарантировать, что дан-ные этих разных компаний никогда не будут видны друг другу. Это как раз и можно реа-лизовать путем использования кластера в качестве сервиса

• Требуется доработка конфигураций в той части, которая должна учитывать модель функционирования.

— Отдельные информационные базы абонен-тов с индивидуальными конфигурациями• Профили безопасности. Механизм, обеспе-

чивающий изолированность базы абонента от внешних ресурсов

• Не требуется или требуется минимальная доработка конфигураций.

Внешняя активность конфигурации (регулируется профилями безопасности).

• Информационные базы располагаются в отдель-ных базах данных и их данные изолированы. Од-нако, конфигурации имеют доступ к внешним, по отношению к 1С:Предприятию, средствам:

— Файловая система сервера — Объекты COM — Внешние компоненты 1С:Предприятия — Внешние отчеты и обработки — Приложения операционной системы — Ресурсы интернет

• Безопасный режим исполнения кода позволяет запретить внешнюю активность кода, не являю-щегося частью конфигурации

Профили безопасности – вообще интересный ме-ханизм. С помощью профилей безопасности можно реализовать гибкую настройку ограничений, а так-же доступ к внешним ресурсам. То есть, вроде как, с одной стороны, иногда нам нужно ограничить работу с внешними ресурсами. Есть режим безопасного ис-полнения кода, который значительно ограничивает доступ к внешним ресурсам, чтобы не нарушать поли-тики безопасности. Но этого не всегда хватает. Потому что, иногда хочется внести ограничения, но при этом оставить больше возможностей. А с другой стороны, можно и не ограничивать, а просто немножко уре-зать возможности. Профили безопасности – это как раз тот механизм, который позволяет это сделать.

• Профили безопасности определяются в рамках кластера

• Позволяют администратору кластера контроли-ровать разработчиков конфигураций и внешних отчетов/обработок

• Профили безопасности можно настраивать непо-средственно в конфигурации информационной базы

• Могут использоваться — При регистрации информационной базы — В коде конфигурации

– 95 –


• Профили безопасности позволяют управлять до-ступом из кода конфигурации к внешним по отно-шению к 1С:Предприятию ресурсам:

— Профиль безопасности информационной базы позволяет ограничить доступ к внешним ресурсам для обычного режима исполнения кода конфигурации (если не установлен, то ограничений нет). Устанавливается в свой-ствах информационной базы

— Профиль безопасности безопасного режима позволяет ослабить ограничения, действую-щие в безопасном режиме исполнения кода. Устанавливается в свойствах информацион-ной базы

— При помощи дополнительных профилей без-опасности безопасного режима можно уста-новить специальные ограничения на отдель-ную функциональность (требуется доработка конфигураций). Устанавливается в качестве значений параметра БезопасныйРежим ме-тодов Подключить (метод менеджера внешних отчетов и менеджера внешних обработок) и УстановитьБезопасныйРежим (метод глобаль-ного контекста)

По поводу профилей безопасности – я еще хочу ска-зать… Кто знает, что такое «Заметки зазеркалья»? По профилям безопасности там есть отдельная статья, где вы можете про все это подробно посмотреть.

Производительность

Оптимизация• Оптимизирована работа с различными СУБД:

— Microsoft SQL Server: уменьшено количество блокировок при многопользовательской рабо-те, ускорена работа с временными таблицами, ускорена запись и чтение данных, ускорена за-грузка информационной базы из файла, уско-рена реструктуризация информационной базы

— СУБД PostgreSQL: ускорено обновление ито-гов, реализована возможность размещать индексы и данные на разных физических но-сителях, ускорено обновление конфигурации

информационной базы — СУБД IBM DB2: увеличена параллельность при

работе большого количества пользователей — СУБД Oracle Database: ускорена работа с ито-

гами, ускорена работа при использовании сложных ограничений на уровне записей и полей, ускорено обновление конфигурации ин-формационной базы

• Повышена масштабируемость и производитель-ность кластера серверов

• Оптимизация работы со сложными запросами и большими объемами данных

Вы знаете, что интересно? Самое большое коли-чество задач по оптимизации было сделано в рамках SQLServer. Наверное, это объясняется еще и тем, что мы занимались и вопросом поддержки новой версии SQL Server.

Управляемые блокировки по реквизитам объектов

Здесь представлен хороший пример того, что, с од-ной стороны, мы позволяем более эффективно управ-лять блокировками, а, с другой стороны, механизм «Управляемых блокировок по реквизитам объек-тов» надо использовать все-таки разумно, потому что, если вы задействуете данный механизм, у вас воз-растает нагрузка на систему.

• Возможность блокировки объекта не только по ссылке, но и по произвольному набору реквизи-тов

• Настройка реквизитов, участвующих в про-странстве блокировки

— Поле «Ссылка» и общие реквизиты в режиме разделения «Независимо и совместно» вклю-чаются автоматически

• Дополнительная нагрузка на систему — При записи объекта 2 блокировки – по старым

и новым значениям

То есть, если раньше просто блокировался объект, то теперь, когда реквизиты одного объекта меняют-ся в двух транзакциях, то это, фактически, уже две версии, которые надо потом объединять. Тем не ме-нее, гибкость по управлению блокировками увеличи-вается.

– 96 –


Регистры накопления и бухгалтерии• Установка минимального периода рассчитанных

итогов — Позволяет сократить объем хранимых данных — Ускоряет пересчет итогов — Ускоряет работу неоптимальных запросов

• Полный скан таблицы итогов — Ускоряет запись движений задним числом

Был проработан очень важный момент. То есть, пе-риод расчета итогов можно ограничить с тем, чтобы не лезть во всю историческую информацию. И, напри-мер, при записи движений задним числом значи-тельно ускоряется процесс, потому что не происходит перерасчета всей исторической информации.

Часть решений по оптимизации включена в версию 8.2.18

• Оптимизирован файловый вариант работы — Работа с сеансовыми данными — Запросы на чтение, так и на запись — Ускорены запросы с RLS (локально и в сети) — Сложные отчеты при работе (по сети) — Изменен алгоритм сжатия таблиц ИБ. В ре-

зультате, по большому счету удалось реализо-вать некоторый аналог кластерного индекса, то есть, при реструктуризации используется кластерный индекс и данные размещаются более правильно, более оптимально с точки зрения дальнейшей работы с ними

• Позволяет ускорить работу тяжелых за-просов

• Требует ручного запуска через ТиИ• Желательно выполнять на регулярной ос-

нове• Ускорено открытие управляемых форм• Работа в терминальном режиме.

— Значительно ускорен запуски значительно снижена нагрузка при работе в терминаль-ном режиме большого количества пользова-телей.

Фоновое обновление конфигурации базы данных.

Скажите, у кого обновление информационной базы занимает сутки? У кого – 12 часов? У кого 2 часа? А у остальных сколько? 10 минут?

Смотрите. Работает облако – некая корпоративная система, где подразделения существуют во всех часо-вых поясах России и еще где-нибудь за границей. Си-стема должна работать 24/7.

А как ее обновить? Сложно. Особенно, если объе-мы информации такие, как в «Тандере» – исчисляют-ся в терабайтах.

Эта задача реализовывалась на самом деле доста-точно долго. Мы давно этой задачей занимались. В 8.3 мы ее сделали.

Как происходит обновление в фоновом режиме? В несколько фаз – в фоновом режиме без остановки си-стемы происходит обновление информационной базы. И монопольный режим требуется только на оконча-тельной фазе, когда необходим перенос изменений. То есть, время простоя сокращено даже не в разы. Оно сокращено на порядки. «Технологическое окно» значи-тельно уменьшилось.

• Позволяет для больших баз осуществить обнов-ление конфигурации без длительного переры-ва работы пользователей. Время «технического окна» сокращается в разы, если не на порядки

• Выполняется в несколько фаз

– 97 –


— Предварительный перенос данных — Перенос изменений, сделанных за время копи-

рования (может повторяться несколько раз) — Окончательный перенос изменений

• В конечной фазе – монопольный режим• Не все объекты переносятся в фоновом режи-

ме — В фоновом режиме – регистры, справочники,

документы, журналы документов, последова-тельности документов, бизнес-процессы, зада-чи и т.д

— В монопольном режиме – планы счетов, ви-дов характеристик, видов расчета и т.д.

Я не могу сказать, можно ли вообще убрать необ-ходимость монопольного режима для конечной фазы обновления. Потому что это достаточно сложная тех-нологическая задача. Надо анализировать. У нас люди этим занимаются.

Мы стараемся как можно сильнее сократить время, необходимое на административные задачи, на обслу-живание системы.

Автоматизированное тестирование.

Ну, наверное, это задача всем хорошо известная – хочу запустить, «потыкать», записать… А потом вос-произвести, чтобы это проверяло мои ошибки. При-близительно этот механизм и был реализован.

• Механизм базовой функциональности для автома-тизированного тестирования

• Запись журнала действий пользователя• Не требует модификации тестируемой конфигу-

рации (приложения)• Можно разрабатывать тесты для управляемого

приложения (в том числе и для веб-клиента)• Объектная модель для имитации интерактивных

действий пользователя и их проверки• Доступен при запуске клиента с новыми ключа-

ми командной строки.

Запись журнала действий пользователя (журнал действий пользователя записывается в формате XML)

• Доступен при запуске с ключом командной строки — Новый ключ /UILOGRECORDER

• Может запускаться из конфигуратора• Новые кнопки заголовка• Интерактивное управление с помощью кнопок

— Пользователь должен явно запустить запись в клиенте

— Можно остановить запись, сохранить результат или отказаться от записи

• Формирует результат в виде XML• По окончании записи отображает результат

пользователю• Результат может быть преобразован специаль-

ной обработкой в исполняемый код системы автоматизированного тестирования (будет вы-ложена на ИТС)

– 98 –


Какие новые термины появились в рамках тести-рования?

• Тест(сценарий тестирования)– программа на язы-ке 1С

• Менеджер тестирования• Клиент тестирования

— Управление приложением — Тестируются толстый, тонкий и веб-клиенты

• Менеджер и клиент могут быть подключены к разным информационным базам

Менеджер тестирования:• Доступен при запуске с параметром командной

строки — Новый параметр /TESTMANAGER

• Обеспечивает выполнение теста, передачу ко-манд клиенту тестирования, оценку результатов

• Может управлять несколькими клиентами те-стирования одновременно

— Не может управлять собой• При взаимодействии с клиентом передаются

только примитивные типы — Без ссылок

Кто с Тест-центром сталкивался? Тут идеология тестирования приблизительно такая же. Есть центр управления тестированием (менеджер тестирования), есть клиенты, которыми он управляет. Со стороны ме-неджера идут команды. Клиент присылает обратно данные.

Клиент тестирования• Доступен при запуске с параметром командной

строки — Новый параметр /TESTCLIENT

• Тонкий клиент или толстый клиент в режиме управляемого приложения

• Обеспечивает имитацию интерактивных действий• Взаимодействие через TCP/IP

— Идентификация через имя/адрес компьютера клиента и уникальный номер порта

Веб-клиент, как клиент тестирования• 3 субъекта – менеджер, веб-сервер, веб-клиент

— Web-адрес информационной базы веб-клиен-та тестирования вызывается с дополнитель-ными параметрами• TESTCLIENT и TESTCLIENTID =<Идентифи-

катор> — Менеджер взаимодействует с клиентом че-

рез веб-сервер• Менеджер с сервером через TCP/IP• Сервер с клиентом через HTTP

– 99 –


Веб-приложение тоже можно запустить в режиме клиента тестирования. То есть, для веб-клиента. Но здесь, естественно, необходимо взаимодействие через веб-сервер. Здесь менеджер тестирования с веб-серве-ром взаимодействует по TCP/IP, а клиент, стандартным образом, по HTTP.

Объектная модель• Набор объектов, описывающих логическую мо-

дель интерфейса, собственно говоря – это те объ-екты, которые используются для написания те-стовых сценариев

— ТестируемоеПриложение — ТестируемоеОкноКлиентскогоПриложения — ТестируемаяФорма — ТестируемаяГруппаФормы — ТестируемоеПолеФормы — ТестируемаяТаблицаФормы — ТестируемаяДекорацияФормы — ТестируемаяКнопкаФормы

• Предоставляют некоторые свойства, описываю-щие состояние объектов, и методы для действий над объектами

— Не посылаем клиенту тестирования сообще-ний ОС, а выполняем логические операции.

Ограничения и проверки• Поддерживается работа не со всеми элемента-

ми управления

— В работе нужно опираться на поддерживаемый набор действий

• Набор проверок ограничен — Проверка через получение представления дан-

ных — Проверка результатов выполнения некоторых

функций — Проверка через поиск объектов тестирования — Для проверки данных, сформированных в ходе

теста, нужно обращаться к базе тестируемого клиента

• Механизм будет развиваться — Сейчас механизм автоматизированного тести-

рования еще развивается. Некоторые ограни-чения пока что существуют. Они у нас, есте-ственно, будут задокументированы. Но, тем не менее, мы все-таки надеемся, что этот ме-ханизм позволит вам значительно повысить качество разрабатываемых решений за счет сокращения затрат, необходимых на организа-цию тестирования.

Linux

Linux – уже год работает.

Действительно, когда я показывал бывшим кол-легам, что, берешь приложение, которое работает на Windows, загружаешь его на Linux и оно работает – мне не верили, пока сами не убеждались.

На самом деле, можно не просто разворачивать 1С на Linux «с нуля», можно сразу подключиться к уже существующему кластеру сервера, и, пожалуйста, оно будет работать.

На самом деле, это стало возможным за счет того, что была сделана достаточно большая работа по дора-ботке уровня абстракции внутри архитектуры 1С по отображению пользовательского интерфейса.

В 2003 году на эту тему я собирался писать канди-датскую диссертацию. До написания руки не дошли, но тему я достаточно хорошо знал. Когда я увидел управ-ляемые формы, мне очень хорошо стало понятно, что там было сделано. Объем работы – колоссальный.

– 100 –


Клиентские приложения и средства администрирования для Linux

• Клиентские приложения аналогично приложе-ниям для ОС Windows

— Для конечных пользователей — Для разработчиков/администраторов

• Приложения не требуют переделки (возможны доработки в части системно-зависимых функций)

• Поддерживается файловый и клиент-серверный варианты работы

• Реализованы для архитектуры х84 и х86-64 (Intel)

• Администрирование (сервер, утилиты команд-ной строки, Java-API).

Linux – особенности файловой системы• Регистрозависимость

— Файлы «file.txt» и «File.txt» – разные!• Отсутствие буквенных обозначений дисков• Отсутствие возможности обращаться к сетевым

ресурсам, используя UNC — Только к заранее премонтированным — Либо сторонними приложениями (нет гаран-

тии, что установлено)• Другой разделитель пути: «/» вместо «\»

— Платформа работает корректно

• Новый Файл (“/tmp/file.txt”) и Новый Файл (“\tmp\file.txt”) – ОК

— При работе с внешними приложениями нужно использовать «родной» разделитель

— Новые методы глобального контекста• ПолучитьРазделительПути• ПолучитьРазделительКлиента• ПолучитьРазделительСервера

Те, кто с Linux не сталкивался, таких особенностей может не знать. Для обхода этих особенностей были доставлены некоторые новые методы, позволяющие писать «кроссплатформенные» приложения.

Особенности файловой системы (файловые маски)

• Работа механизмов сопоставления файловых ма-сок различается:

— В Windows “*.*” – все файлы, в Linux:*.*” – все файлы, содержащие в названии точку

— Маски в Linux также регистрозависимы! — Расширенный синтаксис масок в Linux:

• * – любое количество (ноль в том числе сим-волов, допустимых в имени файла

• ? – любой (ровно один) символ, допустимый в имени файла

• [ – класс символов. После открывающей квадратной скобки указывается последова-тельность символов. Соответствует любому из указанных символов. Можно указывать диапазон, используя «-». Описание класса символов завершается «]». Для указания «-» в качестве символа класса нужно указать его первым или последним символом. Если по-сле «[« указан знак «!», то класс описывает все символы, кроме указанных

— Новые методы• ПолучитьМаскуВсеФайлы• ПолучитьМаскуВсеФайлыКлиента• ПолучитьМаскуВсеФайлыСервера

– 101 –


На самом деле – это тоже интересно. Маска «Все файлы» и в Linux и в Windows означают разное. В Linux маска «все файлы», это просто «*». А для того, чтобы в Linux выбрать еще и скрытые файлы, которые начина-ются с точки, надо поставить маску «.*». И таких осо-бенностей достаточно много. Для этого мы, собственно говоря, все эти механизмы закладываем в платформу, чтобы вам об этом не заботиться.

Работа с внешними устройствами и ограниченность в правах в Linux

• Другие принципы работы с оборудованием – важно для разработчиков внешних компонент

• Для разработчиков конфигураций также нужно учитывать особенности

— Например, форма настроек внешней компонен-ты работы со сканером штрих кодов

— Настройка последовательного порта:• В Windows: COM1, COM2, …ит.д.• В Linux: /dev/ttyS0, /dex/ttyS1,или/dev/

ttyUSB0, /dev/ttyUSB1… Зависит от использу-емого оборудования

• Ограниченность в правах в Linux — Работать с правами суперпользователя не при-

нято — Обычный пользователь имеет доступ на за-

пись только к себе в домашнюю директорию, и, как правило в /tmp

— Остальная ФС – только для чтения (к некото-рым ее частям вообще не может быть доступа)

— Для доступа к внешним устройствам – часто тоже нужны спец. права• Например, в Ubuntu для доступа к последо-

вательному порту пользователь должен быть в группе “dialout”

С внешними устройствами работать можно. Мы – работаем. Но, здесь, опять же, просто нужно знать некоторую специфику, как устроена безопасность в Linux.

На самом деле, ничего сложного здесь нет.

Linux – шрифты, Поле HTML Документа• При разработке конфигураций рекомендуется

— Использовать стилевые шрифты — Либо, при необходимости, шрифты из состава

MSCoreFonts — Других шрифтов в разных ОС может не быть!

• Поле HTML Документа — В клиенте для Linux – используется WebKit — В клиенте для Windows – используется

Internet Explorer — В веб-клиенте – тот браузер, в котором работа-

ет приложение (IE, FF, Chrome, Safari) — Отображение страниц может отличаться в

разных вариантах — При использовании свойства «Документ» не

следует использовать специфичные для кон-кретного браузера методы и свойства. Только стандарт!

Linux – COM, OLE, ActiveDocument. Особенности клиент-серверного варианта работы

• Технология COM, OLE и механизмы, их использу-ющие

— Не поддерживаются — Альтернатива компонентам по технологии

COM – компоненты NativeAPI

– 102 –


— Возможности доступа из платформы к внеш-ним приложениям и внешним приложениям к платформе (аналога COM) – пока нет

— Ближайший аналог «COM» для Linux – техно-логия D-Bus, однако пока платформа ее не под-держивает

• Клиент-серверный вариант работы — Вызовы сервера не привязаны к определенно-

му рабочему процессу — Управлять «привязкой» вызова к серверу

нельзя

Поскольку эти технологии на платформе Linux не работают – надо использовать открытые стандарты, интерфейсы, веб-сервисы, внешние компоненты.

Интерфейс 8.3 Такси

• Интерфейс Такси — Удобно — Комфортно — Современно

• Цели — Снизить порог вхождения — Улучшить юзабилити — Предоставить разработчику конфигурации

средства описания интерфейса с учетом спец-ифики приложения

Да, тут есть, конечно, такие особенности, что поль-зователи не поймут. Но, тем не менее, с одной стороны, пользователи ругают, а с другой стороны, они хотят чего-то нового. Когда им приносишь что-то новое, они говорят – нет, я этого не хотел, да?

На самом деле, мы постарались сделать новый ин-терфейс более современным, более удобным.

Есть новые элементы управления, которые делают его более гармоничным. Можно настраивать.

Все сосредоточено в одном окне.

– 103 –


Панели• Редактор панелей

— В конфигураторе задается начальное распо-ложение панелей

— Пользователь может изменить их состав и расположение «под себя» – такая идеология используется в «порталах»

Что важно? Вот это многообразие панелей, кото-рое существует, теперь превратилось в многообразие компоновок.

Вы же просили убрать верхнюю панель, потому что вам прокручивать надо. Теперь, пожалуйста, можете панель или убрать, или переставить ее, как вам удоб-но, можете максимизировать рабочее пространство по своему вкусу, у вас сейчас свобода выбора по организа-ции пользовательского интерфейса огромная.

Пример того, как все пространство, которое есть, отдано под информацию, с которой надо работать.

А можно и по-другому, чтобы как можно больше оперативной информации отслеживалось.

Мобильная платформа 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С делать.

– 104 –


Важно! Можно существующие клиентские при-ложения быстро переделать для мобильной плат-формы. Есть специальные «мастера», которые под-сказывают, где что нужно поправить для того, чтобы приложение было совместимо с мобильной платфор-мой.

Мобильная платформа 1С:Предприятие• Удобное и современное «1С:Предприятие» – пер-

сональный ассистент на Вашем мобильном устройстве

— Для владельцев бизнеса — Для руководителей — Для ТОП-менеджеров — Для менеджеров

• Новые формы применения программного обе-спечения

— Для ежедневного контроля бизнеса — В любое время суток — В любой точке мира

Архитектура Мобильной платформы 1С• Аналог тонкого клиента с локальной БД. То есть,

по сути, мобильная платформа – это аналог фай-ловой базы данных на мобильном устройстве.

• Клиент + сервер, а не просто мобильный клиент• Варианты разработки

— Независимое приложение. Может работать ав-тономно.

— Автономное рабочее место внешней ИС. Оно может синхронизироваться с Backend систе-мой,которая где-то в облаке расположена. При-чем, система необязательно должна быть написана на 1С – это может быть какой-то сто-ронний сервис.

— Универсальное автономное рабочее место (лю-бой тип клиентского места)

• Характеристики рабочего места — Для менеджеров, «полевых» сотрудников, от-

четность для руководителей… — Упрощенная схема данных и интерфейс — Специальная функциональность мобиль-

ных устройств

Это можно разрабатывать быстро в известных, привычных вам технологиях и инструментах. При этом естественно, что мы занимались вопросами интегра-ции с возможностями мобильных устройств.

Характеристики мобильной платформы• Native приложение под ОС мобильного устрой-

ства. То есть, само приложение – это так называ-емое Native приложение, которое исполняется в среде. Оно использует элементы управления. Оно стандартное для мобильных устройств

• В то же время, туда заложен узнаваемый интер-фейс и узнаваемая функциональность, которая присутствует в платформе 1С, что позволяет соче-тать узнаваемый GUI и органичность приложения на мобильном устройстве

• Адаптированы технологии 1С:Предприятия для ПК

• Интеграция с функционалом устройств.

– 105 –


Функциональность мобильных устройств• Возможности мультимедиа (фото, видео и пр.)• Возможности геопозиционирования (geolocation)

и геокодирования. Кстати, это важно, geolocation с английского переводится как геопозиционирова-ние. Потому что геолокация на русском (вы можете посмотреть в википедии) – это зондирование ка-ких-то слоев земли без разрушения… – методом ра-диолокации. Поэтому, на русском языке правильно говорить «геопозиционирование».

• Использование встроенных карт устройства — На iPhone – карты Apple — На Android – карты Google

• Адаптация к размеру экрана• Использованы элементы управления ОС мобиль-

ных устройств

На настоящий момент, в нашем демо-приложении, которое мы будем делать доступным, это показано, как делать.

Сделана адаптация к размеру экрана, также сде-лано три размера иконки, для того, чтобы на экранах с разным разрешением масштабирование картинок было приблизительно одним и тем же.

Разработка мобильного приложения

Все просто. В свойствах конфигурации в свойстве «Назначение использования» ставите «Мобильное устройство». Можете поставить «Мобильное устрой-ство и десктоп». Просто, если вы ставите «Мобильное устройство» – в конфигураторе отключаются те объек-ты конфигурации, которые не доступны на мобильной платформе, а так – все то же самое.

Доступные приложения• Управление небольшой фирмой• Монитор ERP• Заказы

Приложение Монитор ERP сейчас интегрировано с 1С:Управление торговлей.

То есть, как раз там есть система показателей, ко-торая позволяет данные передавать на мобильное устройство, чтобы руководство могло оперативно с ним работать. Можете загрузить, посмотреть.

– 106 –


1С:Документооборот на ладони• Новое решение на платформе «1С:Предприятие

8.3»• Используется сотрудниками 1С для работы• Позволяет работать с почтой на мобильном

устройстве• Работает автономно, периодически соединяясь

с центральной базой• Поддерживает ОС iOS и Android• Демонстрирует новые возможности платфор-

мы и показывает новые подходы к разработке мо-бильных решений.

Достаточно долго мы его уже у себя используем. Наша почта устроена на 1С:Документообороте – одина-ково работает и на планшетах, и на мобильных устрой-ствах.

В первую очередь, мы его оптимизируем для теле-фонов, потому что, как правило, люди носят с собой мобильные телефоны. Хотя для планшетов работает тоже.

Заметки из Зазеркалья. Ресурс, где мы делимся информацией о новинках

• Произвольные области в модулях для организа-ции кода

• Автоматическое сохранение настроек списков• Про multitenancy (Автор – С. Нуралиев)• Про профили безопасности• Про новый пользовательский интерфейс• …

Вот это – заметки из Зазеркалья. Перед прогнози-руемым концом света мы все-таки решили поделить-ся информацией о том, что мы делаем. Потому что вы ждете эту информацию.

Хочется немножко дать вам возможность загля-нуть, что происходит у нас там внутри, над какими тех-нологиями мы работаем.

Я вам очень рекомендую – тем, кто интересуется вопросами облачных решений, прочитать заметку про multitenancy, которая написана Сергеем Нуралиевым.

Также очень интересная вещь – возможности по ор-ганизации кода.

– 107 –

Построение информационной системы современного предприятия на базе СПО (свободного программного обеспечения)

Федор КуликовИТ-Прагматика, Сертифицированный специалист RedHat. Эксперт по эксплуатации 1С + Linux.

От ведущего: Задам вопрос залу: как вы считаете, можно ли полностью инфраструктуру предприятия построить на Windows? На самом деле нельзя. Дело в том, что такая аппаратная часть, как Cisco или роутеры D-Link внутри себя содержат ядро Linux. Ядра Windows в инфраструктуре сетевого аппаратного обеспечения нет. То есть, условно, системы всегда гетерогенны. Фе-дор, у меня к тебе вопрос, который собственно Андрей Аристархов задал аудитории:«У кого сейчас 1С-ная ин-фраструктура работает на Linux?». Помнишь, там все сроками мерялись? Я сказал год. Кто-то сказал 4 года. У тебя сколько?

От докладчика: Сейчас посчитаю. Собственно го-воря, это была седьмая Fedora. Сейчас восемнадцатая. У Fedora релиз раз в полгода. Значит, это было пять с половиной лет назад.

Собственно говоря, что такое СПО? Это свободное программное обеспечение. Философия СПО гласит о том, что это программное обеспечение можно свобод-но передавать, изменять, улучшать и даже продавать без лицензионных отчислений.

История возникновения

Началось все с Ричарда Столмана. В 1983 году им была предпринята попытка создать проект GNU.GNU – это свободная Unix-подобная операционная система.

Фонд свободного программного обеспечения

В 1985 году появился фонд свободного программ-ного обеспечения. На тот момент он занимался тем, что нанимал программистов, и писались программ-ные продукты с открытым кодом. И передавались для дальнейшего развития.

На данный момент этот фонд занимается толь-ко тем, что играет роль «арбитра» – одобряет или не одобряет программные продукты, проверяет, соответ-ствуют ли они свободной лицензии.

Критерии свободного программного обеспечения

Что нам это дает? Как получилось так, что мы при-шли к использованию свободного программного обе-спечения, в частности, Linux?

Мы довольно часто сталкиваемся с тем, что, в отли-чие от бюджетов на железо, бюджеты на программное обеспечение не даются легко. Я не имею в виду сей-час компании, которые занимаются разработкой про-

– 108 –


граммного обеспечения или компании-франчайзи. Я имею в виду конечных потребителей, их IT-отделы. Я десять лет руководил IT-отделом. И в один прекрасный момент бюджет на программное обеспечение составил 150 долларов. К тому моменту я и один мой коллега уже довольно хорошо разбирались с Linux. Более того, я и он уже поставили Linux себе на рабочие станции. И вот, одна из девушек, работающих в компании, зашла ко мне в кабинет, увидела третий KDE и сказала: «Ка-кая у тебя смешная экспиха!» Тут-то меня и посетила мысль о том, что на сервера и рабочие станции конеч-ным пользователям можно поставить Linux, потому что, как минимум, двум третям пользователям будет все равно, а проблема моего бюджета на программное обеспечение тем самым решится.

Вот так – свободная лицензия, собственно говоря, мне и помогла первый раз.

Чтобы ориентироваться в свободном программ-ном обеспечении – поясню. Свободное программное обеспечение свободному программному обеспечению рознь.

GNU General Public License (GPL)

Berkley Software Distribution license

Есть два больших лагеря – сторонники GPL-лицен-зии, относящейся к проекту GNU и сторонники BSD-ли-цензии, относящиеся к университету Беркли.

Основная разница в том, что лицензия GPL стре-мится к тому, чтобы код программного обеспечения, опубликованного под этой лицензией, никогда не был закрыт. Именно на соблюдении этого тезиса настаива-ли, выпуская третью версию, потому что в формули-ровке второй версии этот момент был недостаточно четко оговорен и сохранялись механизмы, позволяю-щие код закрыть.

BSD-лицензия – наоборот, имеет все механизмы для того, чтобы код программного продукта был за-крыт.

Если вы обратите внимание, то Postgres публику-ется именно под BSD лицензией и поэтому пользуется большой популярностью среди компаний, которые вы-пускают закрытый софт.

А для проекта MySQL, который был выпущен под лицензией GPL, с тех пор, как Sun был куплен Oracle, тоже всячески стараются сделать код закрытым.

Преимущество свободного программного обеспе-чения в том, что его можно свободно развивать, то есть делать fork-и (собственные программные продукты, основанные на этом). Можно взять какой-то продукт, который выпускается под свободной лицензией, и сде-лать свой fork.

Единственное, что в случае GPL-лицензии надо упомянуть всех авторов, которые работали до этого и, если хотите закрыть код, надо получить согласие всех разработчиков, которые участвовали в этом проекте. А когда проект большой и над ним работало 1000 разра-ботчиков, становится просто технически невозможно сделать код закрытым.

Свободное – не значит «бесплатное».

Эту фразу можно понимать абсолютно по-разному. Буквально, самой лицензией для СПО никак не огова-ривается вопрос о вознаграждении.

В Великобритании был такой чудесный случай: когда появилась первая версия FireFox, один из пред-принимателей решил ее продавать. Это действитель-но был честный FireFox, записанный на диск, который продавался. Полиция обратила на это внимание и была крайне удивлена тем, что компания, владеющая этим программным продуктом, ничего против этого не име-ла. Ну, сами понимаете, продавать то, что можно взять бесплатно, абсолютно бессмысленно.

Соответственно, на СПО можно зарабатывать дру-гими способами:

• Самый простой из них – выпускать всякие симво-лики, футболки, чашки, кружки…

• На этом тоже далеко не уедешь, поэтому – есть «за-казная разработка».

• Еще, если продукт разрабатывался для использо-вания внутри предприятия, не подразумевая под собой распространение (я опять-таки, имею в виду GPL-лицензию), то, в принципе, коды можно не раскрывать или раскрывать их по запросу. То есть, лицензией никак не оговаривается, что коды надо выкладывать в свободный доступ. Они могут быть

– 109 –

Федор Куликов Построение информационной системы современного предприятия на базе СПО

переданы по запросу. В некоторых случаях на этом тоже зарабатывают.

Самый интересный такой момент – чем, по сути дела, является любой софт для конечного потребите-ля? Как вы думаете, софт сам по себе, как строчки кода, имеет ценность для конечного потребителя?

Я тоже склоняюсь к мысли, что почти любой софт является услугой. Ни свободный софт, ни закрытый софт ценности для конечного пользователя как сами функции не имеют. Если помните, есть такой мульт-фильм про дядю Федора из Простоквашино. Он там с Шариком спорит по поводу холодильника, который был взят напрокат: «Холодильник чей? Государствен-ный. А холод, который он дает? Он наш. Ради холода мы его и берем».

Все это я говорю применительно к «заказной разра-ботке». Для небольших компаний, которые работают с небольшими клиентами, использование свободного программного обеспечения – это возможность уде-шевить проект, сэкономив на лицензиях на закрытый софт. То есть, они могут платить только за те продукты или «заказные разработки», для которых нет открыто-го софта, который бы удовлетворял всем необходимым потребностям в данном случае.

А как еще можно заплатить разработчикам – не платя денег?

• Можно вносить изменения в код и возвращать его обратно, то есть, делать патчи.

• Можно просто сообщать об ошибках, это тоже большое подспорье. Кто когда-нибудь писал боль-шие вещи – те понимают, о чем я говорю.

• Соответственно, нельзя исключать еще такую со-ставляющую программного обеспечения, как воз-можность воздействовать на конкурента. Речь, опять-таки, о больших компаниях. Когда похожий продукт покупается и у этого проекта появляется инфраструктура – его можно распространять. И, тем самым – выдавливать аналогичные платные продукты. Особенно ярко заметно это на примере баз данных.

Продолжим дальше по истории.

Я расскажу, как же так получилось, что есть боль-шой набор программ, распространяющийся под сво-бодными лицензиями, и можно ли их приспособить так, чтобы полностью построить инфраструктуру предприятия на свободном программном обеспечении.

Начнем с самого простого – с архитектуры.

Portable Operating System Interface for Unix (POSIX)

На тот момент, когда велась разработка проекта GNU – уже существовало множество программ, спо-собных работать через интерфейс POSIX, но готово-го ядра к этому набору программ еще не было. Именно тогда Linux, разработку Линуса Торвардса, и приняли для разработки ядра операционной системы.

Можно ли использовать какое-то другое ядро? Да. Можно использовать ядро от BSD-систем. И исполь-зовать те же самые программные продукты. Тот же самый GNUKDE и все остальное – они будут работать и работают как с использованием Linux ядра, BSD-я-дра, Solaris… и так далее. Обеспечивается совмести-мость на уровне программного кода. Достаточно пе-рекомпилировать программу с другим ядром – и мы получаем рабочую систему.

Linux дистрибутив

• У нас есть чудесное ядро. Даже несколько. • И есть программы для конечного пользовате-

ля, которые можно спокойно использовать. Таким образом, Linux-дистрибутив представляет собой набор этих программ. В некоторых случаях этот набор программ можно предварительно скомпи-лировать.

• К этому набору программ есть определенный до-ступ.

• И есть пакетный менеджер, который позволяет эти программы легко и свободно устанавливать.

• Ну и, самое главное, есть инсталлятор.

Попробуем оценить, а все ли есть в мире свободно-го программного обеспечения для того, чтобы постро-ить инфраструктуру предприятия полностью на сво-бодном программном обеспечении.

– 110 –


Критерии выбора дистрибутива для предприятия

Такие известные дистрибутивы, как Fedora, Debian, Mandriva – содержат от 15 до 30 тысяч пакетов. И, если во всем этом разобраться, то, наверное, мы найдем все, что нам нужно для построения этой инфраструктуры.

Как подходить к выбору дистрибутива?• Поставка. Как я уже говорил – свободный не зна-

чит бесплатный. То есть – надо выбирать дистри-бутив, который имеет высокую степень поддерж-ки, хорошую инфраструктуру, и им пользуются. Например, есть очень хороший платный дистри-бутив RedHatEnterprise. Несмотря на то, что он платный, этот дистрибутив остается свободным. Скомпилированной программы вы не получите, но исходный код – получить возможно. Отступая от темы – именно этим и воспользовался Oracle. OracleLinux – это не что иное, как перекомпилиро-ванный RedHatLinux с убранными логотипами и всеми теми разработками, которые публиковались по GPL-лицензии.

• Поддержка. Стоимость поддержки дистрибути-ва RedHatEnterprise официальным вендором до-вольно дорога. Одна рабочая станция начинается от 140 долларов примерно в год. Сервер – от 3000 долларов в год.Поддержка 24/7 стоит еще дороже.Если такая поддержка не нужна, но уж очень нра-вится то, что делает RedHat – можно воспользо-ваться пересобранным дистрибутивом, совмести-мым с RedHat-ом на бинарном уровне, например –CentOS.Полностью совместимо с RedHat, можно даже под-ключать RedHat-овские репозитории, и, соответ-ственно, наоборот – будет работать.Обновления и срок жизни дистрибутива. Сле-дующий показатель, который надо учитывать при выборе дистрибутива, – это срок его жизни. RedHat-ом поддерживается два дистрибутива – RedHatEnterprise и Fedora. У Fedora срок поддерж-ки – год. Частота выхода дистрибутива – раз в пол-года.Замучаешься обновляться. А через год, не будет об-новлений и, в случае какой-то «дыры», либо само-му разбираться с этим, либо переходить на что-то другое.

У «долгоживущих» дистрибутивов – срок поддерж-ки от пяти лет и выше.Ну, например, RedHatEnterprise поддерживается от пяти лет.

Есть такая модная библиотека ITIL, которая реко-мендует сервисный подход к построению IT-инфра-структуры предприятия. Воспользуемся ее советом и оценим, какие же сервисы нужны в компании

ИТ-сервисы предприятия

Базовые сервисы – те, которыми пользуются все – и пользователи о них даже не знают

• Управление сетью TCP/IP. Это те низкоуровневые протоколы TCP/IP, без которых системные адми-нистраторы жить не могут, а конечным пользова-телям они неинтересны

• Центральная авторизация и аутентификация пользователей – служба каталогов. Тоже необходи-мая штука – очень удобно, когда в компании боль-ше 5 человек. Когда речь идет уже о сотнях человек – без центральной авторизации и службы катало-гов уже деваться некуда.

• Файловое хранилище потребуется для документов • И т.д.

Linux и сеть Internet

С сетью все хорошо. Как известно, CISCO отказалась от своей операционной системы в выпускаемой ею ли-нейке сетевых устройств Linksys. Поэтому там спо-койно крутится ядро Linux со всеми вещами, имеющи-ми отношение к маршрутизации – фаервол, Apitable… И там все то же самое, что мы видим на больших сер-верах. Если вы когда-нибудь администрировали марш-рутизацию протоколов, то попав в Linksys роутер, вы очень быстро откажетесь от веб-интерфейса и будете работать с теми же самыми утилитами, что и в боль-шом дистрибутиве.

– 111 –


Служба каталогов

Оказывается, у ActiveDirectory существует много альтернатив.

Перечислим только самые известные:• Ныне почивший Sun разработал целых два продук-

та службы каталогов: NIS и NIS+.Несмотря на одинаковость названий – это раз-ные службы каталогов по своим возможностям. NIS+ гораздо более функционален, чем просто NIS – хотя бы исходя из того, что в нем была убрана из-лишняя репликация данных между серверами.

• Ну и такая служба каталогов, как LDAP. — Собственно говоря, началось все тут с

фирмы Netscape – тоже уже ныне не су-ществующей, у которой была разработка NetscapeDirectoryServer – которая долго «ко-чевала» из рук в руки. Одним из известных его правообладателей был AOL. И в 2005 году был куплен RedHat-ом – и то, что возможно было опубликовать под свободными лицензиями, было опубликовано. Так получились такие сер-веры каталогов, как:

— RedHatDirectoryServer — Mandriva Directory Server – клон Red Hat

Directory Server — То, что нельзя было раскрыть в силу ли-

цензий – было переписано. Итак, появился FedoraDirectoryServer или 389 Directory Server, который сейчас встречается в большей части дистрибутивов.

— Ну и такой большой проект FreeIPA, который включает в себя, кроме самих каталогов LDAP, еще DNS, DRCP и другие сетевые службы. Те-перь это модно называть «облаком»

Файловое хранилище

Файловые помойки на предприятии – это «притча во языцех» – чего там только нет. От полезных доку-ментов и заканчивая египетскими фотографиями. Как известно, места там всегда не хватает.

Будем устраивать файловую помойку в Линуксе. Что есть здесь у нас?

• 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.

• File Transfer Protocol (FTP) – протокол передачи файлов. Свободные реализации сервера ProFTPD и VSFTPD. Банальная вещь, всем известная. На вся-кий случай рассказываю – тоже поддерживается.

• SSHFileTransferProtocol (SFTP) – используется SSH (SecureShell) для передачи файлов, шифруются команды и файлы. Это такая универсальная шту-ка, такой «швейцарский перочинный армейский нож». Тоже может использоваться как протокол передачи файлов SFTP для тех, кто за «секьюр-ность». Потому что файлики при передаче шифру-ются. На самом деле – SSH еще можно использовать в качестве других интересных вещей. Например – как туннель для X-сервера.

– 112 –


Служба печати

Здесь у нас есть CommonUNIXPrintingSystem (CUPS) – сервер печати для UNIX. По сути дела – это система управления очередью. Его можно использо-вать не только для целей печати документов, но и для отправки факсов и любых других очередей. Например, Fax4CUPS легко заменяет факс-сервер в компании. Правда, на данный момент это уже неактуально, по-скольку факс уходит в прошлое.

Базы данных

Тут тоже большой выбор.

• PostgreSQL – реляционная СУБД. История разви-тия началась в 1986 году в университете Беркли. На данный момент распространяется под лицен-зией BSD. Характеризуется надежностью и отка-зоустойчивостью, поддерживает базы неограни-ченного размера. Самая любимая разработчиками БД, когда есть необходимость закрывать код. Что я могу сказать? Лично использую эту базу данных в проектах, даже предпочитаю эту базу данных MySQL, поскольку она универсальна, годится как для учетных систем, так и для веб-проектов.

• MySQL – изначально разрабатывалась компани-ей MySQLAB как легкая СУБД, ставка делалась на скорость. Собственно говоря – Oracle покупал SunMicrosystems ради JAVA, но тут ему еще та-кой подарок в виде прямого – пусть небольшого – но конкурента своей собственной базе данных. Поэтому – изначально, когда был раскрыт исход-ный код MySQL – он распространялся под двумя лицензиями – под закрытой проприетарной и под открытой GPL.

— Если кто еще интересуется или занимается веб-разработкой и посещает конференции, от-носящиеся к веб-разработке – то там, в основ-ном – про MySQL можно уже и не услышать. Там будут MariaDBи другие форки MySQL.

• Есть еще такой Interbaseserver – родом из Бор-ланда. Был открыт исходный код шестой версии, и получился Firebird – сервер баз данных. Он ча-сто используется в проектах, которые написаны на Delphi.

Учетная система

Тут – распространяться не будем. Возлагаем надеж-ды на 1С – на версию 8.3.

Почтовая служба

Почтовая служба – до сих пор – одна из тех вещей в Линукс, которая сохранила Unix-way.

Unix-way – это философия, которая гласит о том, что маленькая программа должна реализовывать неболь-шое количество функций, но очень хорошо.

Поэтому, если рассматривать Exchange, то это такой большой колоссальный монстр, который «может все». В unix же немножко другой подход.

• Есть MailTransportAgent (MTA), который занима-ется только тем, что доставляет почту от одного сервера к другому. Здесь sendmail, postfix, exim… В моих любимых RedHat-дистрибутивах даже есть небольшой скрипт, который позволяет «на лету» менять MTA для сервера. То есть – осущест-влять выбор между двумя утилитами в поставке – sendmail и exim. Вот их можно менять в зависимо-сти от вкуса, цвета и предпочтений.

• Internet Massage Access Protocol (IMAP). Есть два протокола – IMAP и не упомянутый здесь POP3, ко-торые уже доставляют почту конечному пользова-телю.Опять таки, два наиболее известных – на слуху – это dovecot и cyrus.

• Спам. Со спамом, опять же – можно бороться открытым программным обеспечением – это

– 113 –


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. И, таким образом – можно эксплуатировать старые седьмые базы без откатывания на старый софт.

– 114 –

Когда сотрудник становится гаджетом

Андрей АкуловГенеральный директор ООО «Вертер. Сенсорные технологии»

От ведущего: Мне вот интересно, допустим, я по-нимаю, что у меня заканчивается «продуктив», и я ста-новлюсь «нажимателем кнопок», – у меня же может в этот момент произойти это внутреннее осознание, я же могу остановиться и сказать – «Что же я делаю? Так дальше нельзя!» – и поменять ситуацию. Разве обычно это редко случается?

От докладчика: Обычно, когда берешься за проект и заходишь с этим проектом на предприятие, ты стал-киваешься уже с тем, что люди привыкли и не хотят ничего менять. В моем опыте ни разу не было такого, что «Ой, е-мое, мы же совершенно неправильно работа-ем. Давайте мы переоценим свою собственную работу и начнем по-другому». Никто не стремится взглянуть на ситуацию со стороны, никому не интересно рефлек-сировать на эту тему.

Я хочу с вами поговорить о бизнесе. О том, как про-давать те знания, которыми вы обладаете, на проектах конечным покупателям. И, в конце концов, заработать себе деньги.

Все, что я буду показывать – это наблюдения за 10 лет моей работы.

Мой путь от программиста до предпринимателя

Это я. Это мои 10 лет работы в разных компаниях, начиная от компаний-франчайзи. Компании, где я ра-ботал, периодически менялись, появлялись ИТ-инте-граторы, мультивендорные компании. Соответствен-но, проекты росли, проекты становились сложнее.

В какой-то момент, когда я понял, что на работу хо-дят люди, этакие «Мистеры Смиты» из «Матрицы», я устал.

И тогда я принял решение сделать что-то свое. И в результате я организовал проект «Вертер-терминал покупок», который сейчас успешно и продвигаю.

Но, тем не менее, еще свежи мои впечатления о пре-дыдущих местах работы, и я хочу с вами немножко ими поделиться.

План доклада

Итак, давайте мы сосредоточим свое внимание на четырех главных группах – это

• Заказчик и его сотрудники• Анализ бизнеса клиента – это когда вы пришли к

клиенту и вам нужно решить «Что делать?»• Управление проектом – сама команда управле-

ния.• Внутренний мир внедренца – как ваше собствен-

ное мнение мешаетили, наоборот, помогает вам зарабатывать деньги.

Работа с заказчиком

Существует три глобальных мифа о работе с заказ-чиком, которые нам мешают:

• Первый миф – Владельцу компании нужны ин-новации, модернизации, оптимизации, консуль-тации – все эти окна с красивыми иконками и т.д.

– 115 –

Андрей Акулов Когда сотрудник становится гаджетом

Позже я расскажу историю о том, как мне показа-ли, что это не совсем так.

• Второй миф – Техническое задание должны пи-сать сотрудники Заказчика. Мы почему-то ждем, что нам наши заказчики сами дадут какое-то тех-ническое задание. То есть, мы ждем, что они к нам придут и скажут, что нам надо сделать.

• Третий миф – Сотрудники Заказчика обязаны знать такие понятия, как регистры, версии, рели-зы, метаданные. Они должны понимать эту про-грамму. Они должны пройти курс обучения. Они вообще уже все должны быть готовы, на самом деле, к нашему приходу. Мы же, такие мессии, к ним пришли, а они не готовы. Что с этим делать?

• Четвертый миф – хаос не автоматизируется. Есть такое убеждение у многих, и на многих пре-сейлах мы эту тему клиенту двигаем. На самом деле, все это делается замечательно, но немножко други-ми методами.

Миф первый. Заказчику нужны инновации,

модернизации, оптимизации, консультации• Итак, возьмем 2008-2009 год, когда кризис насту-

пил. В качестве компании возьмем производствен-ную компанию, с полным циклом жизни изделия – закупка материалов, производство, склады по всей России, продажи и так далее. Меня вызывают и говорят: «Предложи способы или создай усло-вия для того, чтобы можно было как-то сократить людей». Ход моих мыслей: «Так, бюджеты под это вы мне не даете, значит, я никого привлечь не смо-гу. Давайте подумаем, что мы можем для этого сде-лать».

• После проведения ряда комплексных меропри-ятий (каких – я чуть позже скажу), удалось со-здать условия для сокращения примерно восьми человек из десяти. Скажу сразу – это произошло довольно-таки простыми, понятными, детски-ми методами. Это не технические методы, там не было никакой супер-мега системы, от внедрения которой тут же стало всем хорошо.

• Но у меня в тот момент возник достаточно резон-ный вопрос, и я говорю владельцу этого бизнеса:

• Иван Иванович, объясни мне, пожалуйста, почему раньше, когда были «сладкие времена» вы этой оптимизацией не занимались? Ведь то, что мы сделали, это довольно просто. Это можно было де-лать в спокойные времена, не особо напрягаясь. И всей этой гонки бы не было.

Он мне на это говорит:• Понимаешь, раньше моя компания в месяц прино-

сила мне пять миллионов. Из них на нужды компа-нии у меня уходит три миллиона. Соответственно, я, как владелец компании, забираю себе два мил-лиона. Сейчас ситуация изменилась. Компания стала приносить всего три миллиона. Но я-то при-вык жить на два миллиона. Значит, надо сде-лать так, чтобы на нужды компании достаточно было тратить один миллион.

Вот такая простая арифметика. В тот момент я впервые столкнулся с тем, что логика владельцев не совпадает с нашими ожиданиями и теми красивыми картинками, которые мы им рисуем на пре-сейлах.

Миф второй. Техническое задание

должны писать сотрудники заказчика.• Ну, во-первых, ТЗ читают в арбитраже, если вы

знаете. То есть, если вы ТЗ написали с ошибками, вам будет очень трудно сдаваться по такому ТЗ. Например, в ТЗ написан такой простейший текст: «У программы должен быть удобный интерфейс». Вы пропустили в свое ТЗ такое требование. Как вы будете сдаваться по такому ТЗ? Какие критерии у этого удобства? В результате, когда вы формируете ТЗ, нужно смо-треть на те слова, которые вы пишете, и макси-мально все детализировать с расчетом на то, что вы, возможно, встретитесь с этими клиентами уже в арбитраже.

– 116 –


• Дальше – вторая вещь, которая очень часто встре-чается. Берем предприятие. Когда вы туда прихо-дите, там разные отделы – бухгалтерия, склад, закупка, отдел продаж. Они сидят в своих хороших кабинетах, им там хорошо, уютно. Их, в принципе, ничего больше не интересует. Все, что в их зону внимания не входит, их не касается. А раз это их не касается, то, соответственно, и задание они вам могут написать только в рамках вот этой своей маленькой части. Вы же не будете к каждому при-ходить и говорить – «Пиши мне, пожалуйста, что тебе не нравится».

• Здесь мне сразу вспоминается пример из практи-ки моей работы начальником отдела ИТ, когда мне пришла такая заявка: «Просим нам, бухгалтерам, на каждый из десяти столов в бухгалтерию по-ставить по планшетному сканеру». Конечно, вро-де все понятно. Но возник вопрос – а зачем десять сканеров? Пришел к ним говорю:«Объясните мне, а для чего вам нужен сканер?» Оказалось, они в 1С делают накладную, дальше ее копируют, вставля-ют в Excel, добавляют строчки подписи, распечаты-вают, ставят печать, подписывают. Потом бегут на первый этаж, там сканируют. Потом бегут обратно на второй этаж, из папочки забирают фотографию этой накладной и уже в таком виде отправляют ее дальше на склады. Это к вопросу о некомфортно-сти – им надоело месяцами на первый этаж бегать, поэтому они решили, что им сканер на рабочем столе нужен. Соответственно, вопрос. Что здесь можно улучшить, даже не прибегая к нашим су-пер-мега способностям, как программистов? Самое простое – можно отсканировать подпись и печать и в том же Excel их вставлять. Конечно, мы потом им это в 1С сделали, что можно просто нажать кнопку и накладная сразу уходила с подписью и печатью – они были такие счастливые. Хоп – уже снизились ваши затраты, да? Не потребовалось никаких сложных разработок, тестирования, оптимизации вашего кода. Надо было всего лишь внимательно посмотреть, чем занимаются ваши люди.

Миф третий. Сотрудники заказчика должны все знать

про регистры, версии, релизы, метаданныеСобственно говоря, возвращаясь назад, к тому мо-

менту, когда мы решали проблему сокращения людей, как раз тогда мы очень внимательно посмотрели, кто же чем занимается на предприятии. Как смотре-ли? Приходим в компанию, смотрим, заказ свалился в какой отдел? В отдел приема заказов – и пошли туда ножками. Куда дальше заказ идет? Сюда идет. Что ты здесь делаешь? То делаю. Аккуратненько все записы-ваем. Просто берете и все записываете. Соответствен-но, когда вы сами, ножками, пройдете весь маршрут того, как у вас движется заказ по вашему предприятию, у вас сразу возникнет понимание того, что и где ра-ботает неправильно.

В результате нарисовался такой график.

Точка А на нем – это, когда вы заходите на проект. Предприятие еще мало автоматизировано, персонал, который там сидит, знает и умеет все, но его произво-дительность очень маленькая. Люди работают ночами, задерживаются на работе по выходным.

Точка B – это уже конечный результат.

А точка С – это, когда вы сделали ряд мероприятий по автоматизации работы, в результате которых у вас очень сильно возросла производительность и очень сильно упали требования к персоналу. Здесь возникает «слом модели». Люди поняли, что работать стало про-ще. Состав коллектива поменялся. Вновь вышедшие попали на ситуацию С, когда система уже заработала, проблемы решены, большинство операций автома-тизировано. Эти люди не знают, как система работа-ла раньше. Они видят только то, как система работает сейчас. Вообще, люди обычно любую систему восприни-мают через интерфейс. Поэтому именно над интерфей-сом нужно думать в первую очередь. Как о том, с чем бу-дет работать ваш конечный пользователь, конкретный человек, под которого вы пишете свое решение.

Что происходит дальше? В некоторый момент, ког-да возникла какая-то не очень хорошая ситуация, и вы выявляете эту ситуацию, то вам говорят: «Это не я, это программа так выдала».

– 117 –


Спрашивается: А ты что тут делаешь? Ты не мо-жешь подумать, что в печатной форме у тебя что-то не то напечаталось? Ты не можешь проанализировать, что должно быть не так? Ты не можешь пойти ска-зать об этом?

Не получается. Вот эти девушки – они превраща-ются в таких «гаджетов», почему и тема так названа – «Когда сотрудник превращается в гаджет». Это про-исходит в момент, когда сотрудники заходят в систему на точке С и там начинают с этой системой работать.

Здесь вам надо вашу систему либо как-то стопо-рить на этом уровне, загонять ее назад, увеличивая ее сложность, чтобы сотрудники, все-таки, проявляли какие-то умственные способности. Либо же вести этот этап до конца и исключать человека вообще из систе-мы – заменять на программу-робота. То есть, когда вам начинают говорить, что это не мы, это система так выдала – это первый признак, что вы находитесь в ситуации, когда надо что-то предпринимать.

Анализ бизнеса клиента

Итак, мы посмотрели заказчиков, посмотрели со-трудников. Теперь давайте посмотрим ситуацию, ког-да вы зашли на предприятие. Что нужно делать в этот момент?

Можно применять Agile-технологии, можно при-менять PMBoK, можно применять Lean-технологии, можно еще какие-то технологии применять… Все это красиво звучит, но на практике, чтобы это сделать, нужно столько мозгов туда потратить. И, тем более, когда отсутствует пошаговая инструкция, это иногда бывает проблематично. Поэтому, в любом случае, на-чинать надо с простых, не затратных вещей.

• Во-первых, я предлагаю использовать метод «Сле-дования за заказом», о котором я немножко уже упомянул.

• Дальше – поработать над налаживанием кон-такта с рядовыми сотрудниками заказчика.

• И, собственно говоря, третий этап – это создание психологических якорей.

Как вы видите, во всем этом 1С даже и близко нет. 1С у нас выступает как инструмент. А здесь рассматри-ваются немного другие вещи. Давайте поговорим на эту тему.

Метод «Следование за заказом».

• Опять-таки, пришел к вам заказ, и вы должны сами пройти по всему пути. То есть, фактически, вы должны понять, как работает бизнес. Не смотреть на этот бизнес через монитор, а именно пройти ножками. Посмотреть, как это все работает. Сами. Не надо для этого никаких сложных техноло-гий. Возьмите обычный лист бумаги, обычный карандаш и запишите, кто что делает – по всей цепочке. Попытайтесь на этом этапе определить, какие процессы добавляют стоимость, а какие лишние процессы. Не надо даже их классифициро-вать как-то сложно. Просто чисто субъективно – вот это добавляет стоимость, а это – не добавляет. Вы уже сразу поймете, на что следует обращать внимание.

• Дальше – обращайте внимание на действия со-трудников. Как они работают. Выявляйте сим-птомы проблем. Для того чтобы выявлять сим-птомы проблем, к сотрудникам заказчика надо сначала найти подход. Вот как вы будете общать-ся с ними? Авторитарно – «Скажи мне, как ты ра-ботаешь?» Или, может быть, как-то более мягко? Может быть, подойти не сразу «в лоб», а просто пообщаться, чай вместе попить, конфетками их немножко задобрить… Может быть, имеет смысл на этом этапе немножко поработать? То есть со-здать нормальные отношения. В результате у вас возникает такая ситуация, когда вам начина-ют жаловаться. Точнее, все-таки не жаловаться, а рассказывать о своих бедах. У каждой компании много бед. А у сотрудника, который там работает, этих бед еще больше. Для вас это первый знак того, что вы должны это брать «на карандаш». Но при этом не надо все их беды «брать на карандаш». Вы там приходите, они же вам все рассказывают – о своей семье, о своих мышках, о своих собачках, о начальниках, о знакомых… Фильтруйте этот мо-

– 118 –


мент и фиксируйте только ту информацию, кото-рая относится непосредственно к вашему бизнесу, и просто спрашивайте. Не доказывайте, не убеж-дайте их, что 1С такая замечательная, не говори-те, что это конфигурация, которая закрывает все потребности. Просто спрашивайте: «Расскажите, а как вы это делаете? Ой, как интересно! Слушайте, а зачем вы так делаете?» Пообсуждайте с ними эту тему. Им интересно это будет.

• Дальше – когда вы собрали этот массив инфор-мации, его надо классифицировать. Неважно, в какой форме. Не надо здесь сложные системы сра-зу внедрять. Обычный карандаш, обычный Excel, Word или даже просто стикеры, которые вы на-клеиваете. Итак, классифицировали, определили наиболее явные зоны проблем. На самом деле, для того, чтобы пройти по крупномасштабному пред-приятию, нужно всего два дня. И три дня на обра-ботку. В результате у вас получается срез про-блем, с которыми дальше уже можно работать более конкретно.

• Дальше – вы начинаете прототипировать. Это такое новое слово, когда вы начинаете придумы-вать некие решения этих проблем.

• Ну и собственно – «История про муда». Вот вам вчера рассказывали, что есть такое понятие «муда», которое означает потери времени. Но вам не рассказали, а как же этих муд выяв-лять. То есть, вроде как есть некая технология Lean. Она замечательно звучит. А вот где же эту «муду» найти, вам не сказали. А я скажу. Ситуация обратная – людей посокращали на про-изводстве, и тут заказы пошли. Производство ста-ло не справляться. Что делать? Заказы стали сто-пориться, клиенты ругаются… Как вы понимаете, на этом этапе от 1С никакого толку не будет, какая бы она супер-мега-крутая не была. Надо понять, в чем причина. Опять-таки, топайте на производ-ство ножками. И, в момент, когда на производство подается какое-то сырье – например, массив дере-ва (такой кругляк), берете секундомер и встаете рядом с рабочим, который его пилит, и дальше, не выключая секундомер, ножками идете за этим рабочим его тайными тропами. И таким обра-зом, записываете длительность каждого этапа по каждому из видов продукции, которые этот рабочий выполняет. В результате, вы обнаружи-те, что процентов 60 своего времени рабочие просто ходят. То есть, 60% времени – это и есть эта «муда». Вот, он от одного станка идет к дру-гому. Пришел, ждет, пока освободится этот ста-нок. Взял детальку, положил в тележку – пошел обратно. Опять ждет. Вот у него два цеха – один цех, второй цех – маленькая такая ступенька. Ему приходится тратить время на поднимание этой те-леги и опускание ее, только потом он будет даль-ше двигаться. Вы увидите, что станки, которые у вас стоят на производстве, стоят неоптимально.

Вы обнаружите, что для того чтобы раскроить ка-кую-то деталь, рабочему нужно пойти в соседний цех, потом вернуться обратно, и уже дальше об-работать деталь. 1С тут нет. Нужно просто посмо-треть, чем занимаются ваши рабочие непосред-ственно на производстве. Желательно посмотреть в глаза этому рабочему, поспрашивать его, почему он именно так делает. Поговорить с мастерами, с начальниками производства, которые там рабо-тают. Неужели они этого не видят? Того, что вам прямо бросается в глаза. В результате, вы выявля-ете, что 60% муд – это потери времени на хожде-ние, на ожидание, на то, что материала нет и т.д. После того как мы неделю с нашими нормировщи-ками и аналитиками эту сплошную фотографию рабочего дня делали и потом выкатили эти ре-зультаты – начальство очень удивилось. Дальше начался очень интересный процесс – мы начали прямо как в тетрисе станки переставлять. Начер-тили схему цехов, нарезали из бумажки квадрати-ки, и стали их расставлять. Ну и дальше в течение месяца это на практике все расставлялось. Тут же соответственно производительность выросла.

Налаживание контакта с рядовыми сотрудниками заказчика

• Берем сотрудника. Это живой человек. Это не ре-сурс. Меня всегда в компаниях смущало то, что есть «ресурсное планирование». Звучит, конеч-но, классно: «Мы пошли заниматься ресурсным планированием». Но это живые люди со своими проблемами. Поймите, что у него за проблема. Поговорите с ним. Посмотрите, что у него стоит на столе. Вот вы, когда ездите отдыхать, приво-зите оттуда какие-нибудь сувениры, они у вас на столе стоят? Для чего вы их там кладете? Чтобы, наверное, кто-нибудь пришел и задал вам вопрос «Какая замечательная штучка и зачем она у вас тут лежит?». Если кто-нибудь придет, вы ему на полча-са выскажете информацию об этой штучке, как вы ее покупали и так далее. Вот, уже тема для разго-вора. Фактически, когда вы заходите на предприя-тие и видите сотрудников, обращайте внимание

– 119 –


на то, что у них на столах стоит. Для вас – это те точки контакта, через которые можно этого человека в дальнейшем вывести на разговор. Например, я пришел на производство, мне надо было какой-то вопрос с начальником производ-ства решить. До этого мы с ним не встречались. Я к нему прихожу. Смотрю, у него на столе стоит фотография подводной лодки. А я сам с Севера, он тоже в Северодвинске работал, и мы с ним полчаса разговаривали о подводных лодках, о том, как это все замечательно было. Ну а потом, за последние пять минут, мы с ним соответственно решили все вопросы.

• Другая ситуация. Вы приходите к клиенту и разго-вариваете с главным бухгалтером. Чувствуете, не идет он на контакт. Вы ему пытаетесь что-то до-казывать, но контакта не получается. Вы задаете ей простой вопрос «Марь Ивановна, что случи-лось? Может, помощь какая нужна?» И вы узнаете – да, у нее с сыном что-то. Или зуб у нее даже болит. Вы сами, например, когда у вас зуб болит, можете думать об автоматизации? Конечно же, нет. Пре-кратите давление, сходите в кафешку, попейте пиво, кофе – как получится. Снизьте этот градус немножко.

• Дальше. Личное знакомство. Ну, все-таки, заходи-те вы на проект не на один день, а на несколько месяцев. Поэтому – выстраивайте отношения с сотрудниками вашего клиента заранее. Инте-ресуйтесь ими. Смотрите, что у них на столе. При-мер приведу.У девчонки на столе стоит обычная фотография котика. Я ей говорю – ой, какой у тебя замечатель-ный котик. Он, наверное, у тебя дома бегает. Она отвечает – нет, это моя мечта. Я хочу такого вис-лоухого британского котенка. А я ее первый раз вижу – как раз впервые всех сотрудников обходил. Я ей говорю – оставь мне свой телефон. Вдруг у меня в Москве этот вислоухий образуется, и я тебе его привезу. Как вы думаете, что я дальше сделал в Москве? Ну, понятное дело, я провел ряд меропри-ятий, чтобы найти этого вислоухого, но ей об этом не сказал. В результате, когда я ей через неделю привез этого котика, у меня на ближайшие три ме-сяца вообще проблем с этим отделом не было. Как вы думаете, они мне акты подписывали?Понятно, что вы выстраиваете новую систему. Понятно, что на первом этапе эта система не-совершенна. До оптимизации, которую Вячеслав с Андреем Гилевы делают, вы даже близко не до-шли. Вам сейчас надо хотя бы скелет сделать работающий. В результате у вас возникают шеро-ховатости. И либо вам помогают на этом этапе сотрудники, либо они вам не помогают.

• Ну и, ребята, личная гигиена. Это обязатель-но. Белье менять каждый день. Рубашки стирать через день. Толстовки – ну, хотя бы раз в неделю. Смех-смехом, но, когда я прихожу в отдел и говорю «Что вы к нашим программистам не обращаетесь?»

И мне отвечают – «Мы к ним не ходим принципи-ально. У них там плохо пахнет». Ну что тут еще можно сделать в этом плане?! Вот такие вот быва-ют ситуации.

Создание психологических якорей.

Что имеется в виду? Опять-таки, я сейчас не сове-тую, я рекомендую, потому что это работает.

• Вы, когда приходите на предприятие, имейте при себе сладости – шоколадки, конфетки – самые обычные, «Вдохновение» – они стоят 100 рублей. Из своего кармана возьмите, для этого не надо ва-шего руководителя проекта напрягать, чтобы он из бюджета эти деньги находил. Ну не нашел, да бог с ним! Вам же работать на проекте. Принесите эти конфетки, разнесите их по отделам, попейте чай с этими ребятами – они вам столько инфор-мации выдадут! А вы же с этим и работаете!

• Дальше – курилка. Если вы курите, в курилке вы можете узнать много всего интересного. Я вот не курил, поэтому этот источник информации был для меня закрыт.

• Но я эту проблему решил немножко другими спо-собами. Я ее решил тем, что в отделе, который у меня был, я там просто организовал такой чайный стол, на котором были конфетки, пироженки, пече-нюшки, яблочки и т.д. В результате, когда сотруд-ники по всей компании узнали, что, оказывается, в ИТ-отделе есть эти халявные сладости – понят-ное дело, они стали ко мне приходить, ну и, па-раллельно общаясь, я и узнавал информацию «из первых рук». Ну, это же совсем дешевые такие вещи, но вы эту информацию получаете. Не надо ждать, что они вам пришлют эту информацию на монитор. Вы знаете, вот сидите перед монитором и ждете. Ну сходите на производство, поговори-те с этими людьми, с которыми вы работаете.

• Расскажу историю про клоунов. Я приехал на про-изводство, принимать отдел. Говорю – мне с вами надо решить три вопроса. Во-первых, теперь, ка-ждое утро, приходя на работу, вы просто будете обходить ваш отдел. Там комнат немного – шесть штук всего. Их обойти-то за 10 минут можно.

– 120 –


Просто заходите, здороваетесь, говорите «Как дела?», и идете обратно к себе. Я думал, это такая плевая идея – поставил галочку и пошел дальше, следующие вопросы решать. Нет. Мы целый час об-суждали эту тему. Я им пытался объяснять, ребята, ну это в ваших интересах. Нельзя сидеть перед мо-нитором и ждать, что вам пришлют заявку. А если вы один раз обхамили этого сотрудника, ну, слу-чайно обидели. Как вы думаете, он вам напишет какую-то заявку? Не напишет. В результате, мне не удалось их на это дело сподвигнуть. Они мне ответили вот так вот «Мы что, клоуны, ходить по отделу?» Так они и сидели. Ходил я.

Управление проектом.

• Был здесь сегодня слайд, где показывали потреб-ности рынка труда в специалистах 1С. В ближай-шее время, судя по всему, специалистов 1С много не появится. Марсиане со знаниями 1С не приле-тят. Значит, надо с этим что-то делать. Поэтому первая тема, которую мы здесь рассмотрим, это разделение труда в команде.

• Дальше – документация проекта, которую вы го-товите.

• Следующее – пресейлы, презентации, сдача про-екта, тендеры – это все необходимо, когда вы от-читываетесь перед вашими клиентами.

• Ну и, собственно, один из вопросов, который я не мог не поднять – это, извините, «Война полов». Когда на проекте работают ребята, девчонки, со стороны заказчика и со стороны клиента – и что между ними происходит. Всякое бывает. Иногда союз, иногда война. Я вообще считаю, что это тема отдельного доклада. Если кто-нибудь ее разовьет, я думаю, популярность будет.

Разделение труда в команде.

• Самый простой вариант «Программист – заказ-чик». Это когда вы работаете на предприятии, и вы, как программист, решаете консультационные во-просы, консультируете, решаете, программируете…

• Дальше – типичная схема работы франчайзи: когда есть заказчик, есть руководитель проекта, есть консультант и есть программист. Руководи-тель проекта берет на себя функцию технического руководителя. Он как бы и функциональную часть решает и в том числе и организационные моменты тоже решает.

• Когда вы переходите чуть выше или проект стано-вится немного сложнее, вам необходимо функци-ональную часть и техническую часть выделять в отдельный функционал. Появляется архитектор проекта.

• Иногда бывает еще сложнее – когда еще часть ар-хитектора делится на архитектора системы и технического архитектора.

Ну, собственно, вряд ли вы найдете нужное коли-чество ресурсов, чтобы закрыть все эти позиции. Зна-чит, надо менять модель. А как можно менять модель? Во-первых, не каждый проект потянет «руководителя проекта, архитектора, консультанта, программиста». Значит, надо что-то предложить другое.

Например, я пытался продвинуть идею, что роль архитектора можно вывести на более высокий уро-вень, чтобы он управлял несколькими проектами.

И вообще, вы внимательно посмотрите, а чем же конкретно занимается каждый ваш специалист? Консультант, программист, архитектор? Проведите фо-тографию рабочего дня – чем он занимается? Понятно, что работа занимает все отведенное время. Понятное дело, что ваши сотрудники в системе, где они отчиты-ваются, как потратили свое рабочее время, зафиксиру-ют 8 часов. Но это – нулевая информация. То же самое, подходите к ним и смотрите, чем они занимаются. Ок, он был на интервью, записал разговор на аудио пленку. Он занимается тем, что он три часа расшифровывает эту информацию. А ему надо было тратить на это свое

– 121 –


время? Или расшифровку этого интервью можно было отдать на аутсорс?

Как мне кажется, именно в этом направлении наше с вами будущее. Нам надо самим повышать собствен-ную производительность. А увеличение количества людей в проектной команде – это, как мне кажется, как раз тупиковый путь, тем более что специалистов больше не становится. Все новые компании, которые сейчас появляются, жалуются, что у них не хватает ре-сурсов.

Документация проекта.

• Я не знаю, как это вам рассказать, но суть такая – вообще-то все директора, которым вы сдаете до-кументацию – они хотят ее видеть в красивом виде. Желательно, без ошибок. Лучше, чтобы там было как можно больше картинок. Потому что текст очень плохо воспринимается. Поэтому кар-тинки, визуализация – работайте над этим. Если в тексте есть отражающие суть картинки, вы сразу подниметесь на следующий уровень. Если вы про-сто гоните текст, то это не очень хорошо.

• Дальше – инструкции. Инструкции мы все время пишем. Это довольно противное занятие, но его делать надо. Как выглядит идеальная инструк-ция? Вспоминаем плакаты ГО и ЧС. Или вспоми-наем самолет, когда нам надо провести эвакуа-цию. Вспоминаем комиксы. Вот она, инструкция. Но, чтобы такую инструкцию подготовить, нам необходимо провести комплекс мероприятий по анализу процессов, по их описанию, по регламен-тации и т.д. и т.п. И только потом, на конечном этапе, вы выводите эту инструкцию, красивую, с картинками. Например, отдел качества. Сидит девушка, которая должна поднять телефон и ска-зать «Добрый день! Меня зовут Марина, компа-ния такая-то. Чем могу быть полезна? » Вы так в этой визуализированной инструкции и рисуете: девушку, которая улыбается, которая поднимает трубку, и говорит вот этот текст, чтобы она его ви-дела и понимала, что от нее требуется. Обычный текст они читать не будут. У меня не читали. Мо-жет, у вас читают.

• Дальше. Внимание к деталям. Простейшая ситуа-ция. Берем схему процесса. Берем ее описание. Бе-рем ссылку на этот процесс где-нибудь в документе. Желательно, чтобы наименования этих процессов были одинаковы. И обязательно проверяйте пе-ред отправкой те документы, которые вы сдаете вашим клиентам.

• Почему? Потому что я сам этим страдал в свое время. Вроде, сделал первую версию докумен-та и отправил ее клиенту, прокатило – замеча-тельно. Не прокатило – немножко подправлю. На самом деле, на первом же этапе надо сделать сразу по этому документу хотя бы три итерации – чтобы этот документ проходил проверку вну-три своей компании. Сами проверяйте, что у вас пишут ваши сотрудники.

• Каждый документ – берете его, смотрите. Ошиб-ку одну нашли – всем, кто подписал документ, штраф 1000 рублей. Можно чуть больше – 100 бак-сов. Когда я работал в компании, которая занима-лась тем, что описывала бизнес-процессы, с меня и моих коллег брали штраф за ошибку – 100 баксов. Мы тогда готовили такой большой пакет докумен-тов – схемы, описания, инструкции, примеры и т.д. И если президент компании находил хоть одну ошиб-ку – все, кто подписал, получал штраф 100 баксов. Соответственно, после третьей-четвертой итера-ции ты уже смотреть не мог на эти документы. Ты уже настолько их выверял… Сразу скажу, надолго меня в этой компании не хватило. Но зато теперь, когда я на проекты прихожу, я уже сразу вижу те ошибки, которые делают другие сотрудники.

Пресейлы, презентации, сдача проектов, тендеры

Вы никогда не задумывались, почему на тендерах выигрывают некоторые компании? Вот как так полу-чается? Вроде и вы там были, и вы туда заходили, а вы-игрывают они.

• Вообще говоря, перед тем, как выйти на некий тен-дер – сначала нужно попасть на эту компанию, чтобы понять, что им нужно «изнутри». Потому что один человек на запрос: «Приезжайте к нам, покажите нам возможности УПП» – будет просто

– 122 –


ехать и показывать. А другой – сначала съездит на предприятие, поговорит с ключевыми людьми, тем более, на это много времени не надо. И, соот-ветственно – уже на презентации будет прогова-ривать тот текст, который от него ожидают. Это первый вариант.

• Второй вариант – сделайте из презентации како-е-то шоу. Не просто текст. Не сидите, уставившись в компьютер. Компьютер здесь, зал где-то там и вы читаете. Замените текст картинками.

• На самом деле – банальная раздатка. Надо раздат-ку иметь обязательно. Потому что на это меропри-ятие тоже приходят сотрудники вашего клиента. Им тоже скучно. Им хочется в руках что-нибудь потеребить. А они сидят, ничего не делают. Они на вас смотрят. А если вы еще и скучное что-нибудь рассказываете, то они вообще ничего не понима-ют. А раз им скучно, они еще и негатив копят к вам. Дайте им хотя бы картинки какие-нибудь краси-вые посмотреть, пусть они хотя бы их полистают.

Внутренний мир внедренца

Я думаю, что в зале очень много тех, кто уже 10 лет в профессии. Правда же, возникает иногда чувство, что уже скучно становится этим заниматься. Вот мы уже 10 лет этим занимаемся, проекты появляются, а куда нам дальше двигаться?

Оцени свой профессионализм

• У меня есть знакомые, те, которые для себя ре-шили, что хватит заниматься проектами. Сколь-ко уже было этих проектов, сколько мы их уже сделали, сколько мы их еще будем делать. И они решают: а давайте-ка мы перейдем, например, в продажники. Хоть какое-то разнообразие. А неко-торые говорят – да мне вообще все это надоело, я пойду дом строить. И уезжают дом строить.

• В результате, карьера – это такая очень интерес-ная вещь. Знаете, вам вроде бы и хочется туда, на-верх попасть, а не получается, потому что там тоже сидят молодые руководители, которые еще лет 10 планируют там посидеть, если им тоже скучно не станет.

• Что делать в этом случае? Можно попробовать по-смотреть на себя со стороны. Знаете, наверное, на проектах бывает такое, что в команде заказчи-ка встречается сотрудница, которая говорит, что в прошлом она заканчивала какой-то программист-ский институт и где-то работала инженером. И, соответственно, утверждает, что она тоже в этом что-то понимает. Ну, там-то она понимала, но сей-час технологии изменились и она уже немного не в теме. Так вот, я надеюсь, мы с вами все-таки не бу-дем программистами из прошлого. Потому что, чтобы «быть в тренде», нам тоже надо меняться.

Собеседования и ошибки компаний при общении с кандидатами

• Задайте себе вопрос – а сколько вы стоите? Надо ходить на собеседования. Походите. Это очень хо-роший навык. Вы много узнаете о себе и многое узнаете об этой компании.

• Вот сейчас, по идее, мне надо бы компаниям дать совет, но давайте я через сотрудника буду указы-вать на те ошибки, которые совершают компа-нии, когда приглашают на собеседование кан-дидатов. И жалуются потом, что к ним кандидаты не приходят, потому что они хотят много денег.

— Первая ошибка: если вы им резюме отправили, зачем вы с них требуете на собеседовании еще и анкету заполнять? Оно вам надо? Зачем?

– 123 –


Те, у кого мало опыта – они могут это «съесть». А те, у кого опыта достаточно, хотят с вами поговорить о том, зачем они нужны этой ком-пании. Уберите этот барьер. Не надо закры-ваться от специалиста.

— Дальше. Анкету ладно, все-таки дали, но не пи-шите таких слов «Укажите болезни, которые помешают вам работать в нашей компании». Ну что за бред?

— Дальше. Что еще возникает у нас на собеседо-вании?Вот я, на самом деле, роль кадров в этом деле вообще свел бы к минимуму. И оставил бы на них только – встретить и провести к руково-дителю отдела. И не портить отношения с по-тенциальным кандидатом. Подумайте над тем, где вы их встречаете, в какой переговорной. Кандидаты же ходят в разные места, и в разных местах их встречают по-разному. Если крупная компания их встречает в маленькой переговор-ной и в этой переговорной грязно, а его еще не угощают, а у него 10-летний опыт. Вот у вас 10 лет опыта. Как это так – вы пришли на собе-седование и вам кофе не предложили! Это что такое! Вы же уже наработали себе некую репу-тацию, а тут подвергается сомнению, что вы профессионал! Вам тут еще дают какие-то те-сты, которые составил непонятно кто, и вы еще на эти тесты должны отвечать. Ребята, да я уже кучу проектов за эти 10 лет сделал! Поговори-те со мной о тех проектах, которые я делал! Зачем от меня ограждаться этими тестами?

• Анекдот про HR:HR–директор умирает, попадает к Архангелу Миха-илу. Архангел Михаил говорит: у нас сейчас новый порядок. Соответственно, сейчас у нас есть выбор. Ты можешь выбрать либо рай, либо ад. HR-дирек-тор говорит: «ого, как прикольно, ну давай я рай выберу». Ему Архангел Михаил на это говорит: «ты сначала сходи туда, посмотри, как в раю, потом де-нек в аду побудь. А потом придешь и выберешь». Значит, тот в рай приходит – там все красиво, на облачках играют арфы, все цивильно. Потом попа-дает в ад – там его встречают его друзья, HR-дирек-тора. Они его приглашают поиграть в футбол. Они целый день развлекаются – никакого подвоха вро-де нет. Тогда HR-директор идет обратно к Арханге-лу Михаилу и говорит – «Знаете, я тут подумал. На-верное, я все-таки выберу ад. Там все-таки все уже знакомые, там так интересно – давайте-ка я туда пойду». Архангел Михаил ему говорит «Ну, как хочешь». Спускаются на лифте в ад, там пустырь, бумажки летают, котлы варятся. В котлах его же друзья сидят. HR-директор в ужасе «Как же так произошло?» Ему объясняют: «Понимаешь, вчера было собеседование. А сегодня уже работа». Поэтому, не надо гнать сказки на собеседовании и рассказывать, какая вы крутая компания. По-

тому что завтра это сыграет против вас. То есть, если вы берете специалиста под проект, поговори-те с ним, подо что вы его берете. А если у вас проек-тов нет – ну зачем его смущать-то?

Готовы что-то менять?

Проект Доминикана – все знаете. «Первый БИТ» сделал шикарную вещь. Мне кажется, это – первая ла-сточка. Я думаю, что сейчас если какие-то еще ком-пании пойдут по этому направлению и начнут при-влекать сотрудников не в штат, а под проекты, и эти проекты будут как-то упаковывать, это позволит сра-зу набирать нужную команду.

Обратите внимание – 124 участника. 124 человека, которые уже работают в разных компаниях, которые приносят этим компаниям деньги, и эти люди теорети-чески готовы сорваться и пойти на этот проект. Взяли только восемь. Что они будут делать с этими 124-мя, я не знаю. Мне кажется, это отдельная тема для разго-вора.

Я думаю, что если компании начнут в этом плане что-то придумывать, то рынок будет интересно ме-няться.

Мой выбор. Я – предприниматель!

Так, ну и, собственно говоря, я для себя сделал вы-бор. Я решил попробовать себя в новом качестве. Я по-


смотрел, что появляются новые технологии, Windows Azure.

Тут предпосылка какая – вы можете как угодно от-носиться к слову стартапер. Мне оно тоже не нравится. Да, но, все-таки, в самом слове «предприниматель-ство» – там тоже заложен смысл – когда ты сам дела-ешь что-то.

• Во-первых, на что вы можете теоретически рассчи-тывать – господдержка 500 тысяч. Причем они жалуются, что у них нет заявок.

• Фонд Бортника буквально на днях выставил но-вый конкурс, где компании могут подать свои заявки на какое-то инновационное решение или продукт и получить 15 миллионов.

• Дальше – Сколково предлагает один миллион ру-блей.

• Ангелы, инвесторы, менторы – тоже очень инте-ресные на самом деле люди. Когда вы туда попаде-те – это целый мир.Точно так же, как и мы, когда приходим на произ-водственное предприятие и смотрим, как там ра-ботают, так же и эта стартап-тусовка – у нее тоже

свои особенности, свой язык. Его нужно просто понять. К нему нужно относиться как угодно, но у них свой язык.

• Ну и, конечно же, вас ждут сомнения, решения и успех.

• История про море – в чем суть? Вы сейчас на бе-регу. Вы получаете стабильную зарплату. У вас все хорошо и вы никуда не двигаетесь. Возможно, у вас есть кредиты, какая-то ипотека, которая вас дер-жит. И, в принципе, если у вас зарплата хорошая, то вы еще очень подумаете, а стоит ли туда идти. У вас вроде идеи есть, вы готовы их реализовы-вать. Но что-то вас останавливает. Вы на берегу. А там – море. И вот, когда вы начинаете плыть – ну хотя бы один шажочек сделать – хотя бы фир-му зарегистрировать, еще что-то. И вот, когда туда дальше-дальше плывете, вы понимаете, что, что-бы вернуться обратно на берег или доплыть до некоей вашей желаемой цели, для вас примерно одно и то же время нужно потратить по усилиям. Преимущество в том, что, когда вы начинаете плыть, у вас появляются очень интересные воз-можности.

– 125 –

Подходы к управлению проектной организацией

Сергей ЛебедевДиректор компании ITLand (itland.ru), Координатор по развитию направления «1С:Решения для управления проектами»

От ведущего: Сейчас будет выступать представи-тель компании ITLand. 10 лет назад я очень многому учился именно у них на сайте. Мир вообще квадрат-ный… А поскольку конференция у нас управленческая, мы знаем, что есть процесс разработки. И есть люди высокоуровневые, которые строят процесс. В SCRUM-е у Асхата Уразбаева это называется SCRUM над SCRUM-ом. То есть, если есть процесс SCRUM, то есть процесс SCRUM для тех людей, которые организуют процесс SCRUM. Верхнеуровневая такая кибернетика. То есть это процесс для тех, кто строит процесс. Сергей, я не ошибся, описывая тему твоего доклада?

От докладчика: Я немного уточню. У нас в ком-пании есть такое понятие – проектно-процессный ду-ализм. Как раз когда все вечером в пятницу решают что-нибудь пообсуждать и начинаются споры на тему: что важнее – проекты или процессы, когда проект пре-вращается в процесс и обратно. Компании могут вы-полнять процессы (обслуживание, например), компа-нии могут выполнять проекты, а сам этот бизнес, если расценивать, что его кто-то открывает и через три года продает, это – бизнес-проект верхнего уровня.

Кратко о компании ITLand:

Наша специализация – это разработка и запуск комплексных систем для проектно-ориентирован-ных организаций.

У нас совместно с 1С разработано три основных программных продукта. Мы, собственно говоря, ими и занимаемся – разрабатываем, внедряем, запускаем, ра-ботаем с партнерами.

Также у нас уже достаточно большой портфель вы-полненных проектов, в том числе и корпоративных. Сегодня была преамбула про интеграцию, у нас в рам-ках предприятия «Росатом» был большой проект по интеграции разработанной для них системы «1С ERP «Росатом» с огромным количеством систем, и вопрос «шины» для них там тоже решался, только «шина» была саповская. То есть, мы очень рады тому, что 1С тоже занимается вопросам «шины». Вопрос, как раз-личные системы живут и работают между собой, очень полезный и востребованный.

Что еще хотелось бы сказать важного о нашей ком-пании.

Корпоративный вид спорта в нашей компании – это дайвинг. Наши ребята давно этим увлекаются, занима-ются. Я тоже это немножко проповедую. Ездим, ныряем.

– 126 –


Кроме обычного дайвинга в Красном море и Вене-суэле, есть такие полуэкзотические виды дайвинга, на-пример, ныряние на сноуборде с аквалангом в бассейн с ледяной водой.

Еще – подледный хоккей. Это тоже придуманный нами вид спорта. Я думаю, мы сделаем маленькое ви-део и выложим его на сайт. Если кому-нибудь будет ин-тересно, можно будет его посмотреть.

Ну а на одном из корпоративов мы доставали ядра с затопленного парусника «Портсмут» – это парусник из фрегата Петра Первого. Потом нам одно из ядер по-дарили и сделали на нем гравировку. Оно у нас в офисе хранится.

Про дайвинг я могу рассказывать много, но дальше мы будем говорить про управление, про проекты, про-ектные офисы, проектные организации.

Основные понятия – проектный треугольник и портфель проектов

Проектный треугольник – всем известная вещь. Сроки, результаты, бюджет. Менеджеры удерживают все это в рамках, либо приходят к руководителям и го-ворят – «Вылетаем за рамки, давайте расширять что-то из этого».

Соответственно, мы переходим к портфелю проек-тов. Проектов много. Задача менеджера по проектно-му управлению – это закрыть основные функции:

– 127 –

Сергей Лебедев Подходы к управлению проектной организацией

Проектный офис

Для управления портфелем проектов в компании появляется структура или подразделение, которое у всех по-разному называется:

• Проектный отдел• Проектный офис• Офис управления проектами• И пр.

В этом подразделении есть своя оргструктура, есть руководители, есть управление, есть какие-то дей-ствия. Причем, в разных случаях, степень ответствен-ности этого подразделения может сильно варьиро-ваться.

• От оказания поддержки управления проекта-ми (по сути, это – консультационный центр ре-комендательного характера, где консультируют по вопросам ведения проектов, рассказывают, что у руководителей проектов есть проекты, для ве-дения проекта надо делать такие-то документы, такие-то проблемы на проектах решаются так-то).

• Либо проектный офис занимается прямым управлением проектом (распределением ре-сурсов, контролем, мониторингом, изменением, отвечает за достижение проектом определенных показателей). Обычно проектные офисы не отве-чают за наполнение проектов и ресурсов (наймом сотрудников и принятием решений по открытию проекта занимаются другие люди).

Проектная организация

По организации – то, о чем мы в начале говорили. Организации делятся принципиально на два типа по основному виду деятельности:

• Проектно-ориентированные организации• Непроектно-ориентированные организации

Если основной вид деятельности – это проекты, то, соответственно, такие компании относятся к про-ектно-ориентированным.

Сейчас все чаще и чаще развитие в организациях тоже делается через проекты. Выделяется показа-тель – чего хочет организация достичь, группируются инициативы, делаются некие портфели, назначаются руководители. У них сроки, ответственность, мотива-ция, KPI и пр. В конце периода смотрим – получилось или не получилось. Причем управляемость развития через проекты выше, чем управляемость через про-цессы. Это объясняется тем, что изменениями в ор-ганизации главным образом должны заниматься ру-ководители, потому что у них на это есть полномочия, власть и т.д. Только времени, как всегда, не хватает. А когда это выделено в проект, в том числе выделяет-ся и время ключевых ресурсов, что важно.

Особенности работы проектных организаций: зоны внимания руководителей

Рассмотрим разные аспекты зоны внимания руко-водителя проектной организации.

• Первый аспект – это конкурентоспособность про-ектной организации, как ответ на то, почему орга-низация в будущем получит заказы. Почему она будет жить и работать.

— Почему конкретные заказчики выберут про-дукты и услуги этой организации

— При этом надо понимать потребности заказ-чиков и возможности организации на теку-щем горизонте планирования работы.

– 128 –


• Следующий важный аспект проектной организа-ции – персонал. «Кадры решают все!» А в трудо-емком производстве это вообще самое основное, самое золотое.

• Кроме того, что персонал должен соответствовать очень много чему – об этом чуть попозже погово-рим, важна эффективность работы общей струк-туры организации, то есть, выполнение проектов и заказов должно быть эффективно. Критерии эф-фективности организации определяют по-разно-му. Но, в общем-то, так или иначе, все сводится к проектному треугольнику.

• Появляется важное слово – рентабельность. Про-ектная организация должна работать с положи-тельной рентабельностью, если это не какой-то там инвестиционный проект на какой-то период. И такая компания должна быть платежеспособна. То есть, появляется большой вопрос финансового управления.

• Кроме этого с ростом компании, большую важ-ность в проектной организации получает аспект «Технологии и Знания», как они накапливаются в компании, как они передаются.

• И еще один аспект – «Взаимоотношения». Это мо-гут быть взаимоотношения внутри организации или взаимоотношения с заказчиками, с подрядчи-ками.

• И, как результат всего этого, – общая экономика проектной организации.

Выводы:

• Потребности заказчиков надо понимать глубже,

• Проекты выполнять быстрее,

• И это позволит делать работу для заказчика де-шевле.

Принятием решений по поддержанию и стабилиза-ции этих аспектов и занимается руководитель проект-ной организации.

Так как мы сами проектная организация, и мы автоматизируем проектные организации, у нас сло-жился некий набор наблюдений по работе и решению проблем на проектах. Этот набор наблюдений я поста-рался формализовать и представить в виде какого-то систематизированного материала, который, возмож-но, будет вам интересен. Кому-то для общего разви-тия, кто-то найдет в этом для себя какие-то практи-ческие идеи.

Стабилизация проектной системы – важнейшая задача

Можно ли достигнуть гармонии при работе с порт-фелем проектов? Или приходится мириться с тем, что люди постоянно работают в состоянии агонии, безо-становочно «туша пожары»?

• Проект, проектная команда, проектная система – это изначально нестабильная система. Особенно это проявляется на больших сложных проектах.

• Это можно сравнить с ядерным реактором – его долго создавать, долго строить, вроде все эффек-тивно работает, дает электричество, но все не-множко напряжены, потому что есть нюансы.

Примеры из жизни компаний-партнеров – проблемы, требующие стабилизации

Сейчас я приведу набор примеров. Это примеры из нашей практики, как постановка проблемных ситуа-ций.

Первый пример – есть компания, «села» на крупно-го заказчика и работает. Вроде все прекрасно, но есть нюансы:

• Первое – получается полная зависимость от за-казчика

• Дальше – от заказчика в полный рост идут всяче-ские манипуляции

• Когда проект заканчивается, на старте должен быть схожий проект, иначе проектной команде, которая получила большой опыт, некуда будет «приткнуться», то есть, команда с большой веро-ятностью «разбежится».

Вывод: организация в такой ситуации, при такой зависимости, может погибнуть. Надо заранее думать, что делать дальше, как-то мониторить рынок.

– 129 –


Второй пример: на корпоративный проект выве-ли больше четверти персонала. Как следствие, ока-зались в ситуации, аналогичной примеру № 1.

Когда-то на управленческих уроках говорили, что один заказчик в общем портфеле заказов не должен за-нимать больше четверти оборота, приводили примеры про ИКЕА и пр. То есть, когда маленькие компании по-падают в зависимость от больших ритейлов, то… Если управление конкретно этим заказом берет на себя первое лицо компании – из этой ситуации можно как-то выкрутиться. Если полномочия в такой ситуа-ции делегируются – риски очень высоки, потому что потеря четверти оборота обычно в несколько раз превышает рентабельность организации.

Третий пример – проектов много, но на од-ном-двух проектах начинается завал. Начинают эти проекты «вытягивать», наваливают туда ресурсы, ре-сурсы «выдергивают» из других проектов. Обычные следствия:

• Валятся эти проекты и другие проекты тоже. • Ресурсы тратятся, деньги тратятся. • Более того, возникает ситуация, что «проели аван-

сы», в том числе с новых проектов. В общем, вы-страивается «пирамида долгов».

Вывод тот же – можно погибнуть.

Следующий пример – неоправданно быстрый рост компании. Компания растет быстрее рынка, как-то так получилось. Какая есть в этом случае у компа-нии возможность? Собрать с рынка готовые ресурсы, причем задорого. Потому что это надо сделать бы-стро, и варианты – перекупать. Что получается: люди приходят, но эти люди – не приверженцы компании. Более того, стоимость подобных людских ресурсов может быть сильно завышена. Таким образом, отдачи по проектам может не получиться, а любое колеба-ние может привести к тому, что народ разбежится. И, как следствие, высокие риски потери управления. С этим в реальности столкнулись несколько известных нам компаний.

Еще пример – много проектов, много ресурсов. Функциональная структура компании начинает да-вать сбои. Компания растет, функциональность не работает. Надо что-то предпринимать. Выбирают идею перейти к матричному управлению (когда двойное подчинение ресурсов).

Как известно, матричное управление сложно в за-пуске и применении. Появляются стандартные кон-фликты в матрице между руководителями проектов и руководителями подразделений. Происходит непо-нимание проблемы, непонятно, как лечить.

Вывод – высокие риски потери управления. То есть тем, кто переходит от функциональной системы к матричной, надо как следует взвесить все «за» и «про-тив», пообщаться с людьми, которые это делали. В лю-бом случае, эта новая система приживается долго.

– 130 –


Это были такие страшилки-пугалки, которые, в об-щем-то, являются реальным набором историй с рынка за последние восемь лет. Кто-то может какие-то орга-низации узнать.

Что можно сделать, какие есть подходы к тому, что-бы ситуация на проектах не так шла вразнос. Как мож-но ситуацией управлять?

Первое – это вопрос организационной составляю-щей.

Роль организационной составляющей1. Первое – это правильное выполнение каждого

проекта. Существуют даже специальные стандар-ты PMBoK, которые говорят о том, как правильно выполнять проект:

— Где «подстелить соломку» — Где отработать то, то и то — Какие сделать документы — И т.д.

2. Второе – выбор правильного набора проектов. — Не так давно в PMI появились стандарты управ-

ления портфелями проектов, — В России в прошлом году появились стандарты

по управлению проектами, управлению порт-фелями и программами проектов. Небольшие, но появились уже. Большой шаг вперед – это хорошо.

Главная мысль этих стандартов в том, что компа-ния должна выполнять правильные для себя проекты и выбирать правильные для себя проекты.

3. Третье – это создание среды для успеха проек-тов. Это значит, что если эта компания работает на проектном рынке и занимается проектами, то в компании должна культивироваться проектная атмосфера. Там должны быть:

— Работа с персоналом, обучение, структура поддержки, наставничество и т.д. и т.п.

— Должны нарабатываться технологии, соби-раться базы знаний.

Это те вопросы, которые надо проговаривать, ре-шать, смотреть, чтобы получать какие-то плюсы и дви-гаться вперед.

Задачи проектного офиса

В своей регулярной работе проектный офис решает две важных задачи:

• Синхронизация• Ритм работы

По синхронизации – поясню, какой смысл вклады-вается в это слово.

Особенности мультипроектного управления

Если мы говорим об одном проекте – то:• У него есть рамки, время, бюджет. • Проект направлен на решение какой-то уни-

кальной задачи, создание какого-то уникального объекта – проектной документации, изделия, ав-томатизированной системы – не принципиально.

• Проект состоит из набора процессов, которые выполняются.

• Проект может иметь выделенную проектную структуру. Это означает, что в проекте есть ресур-сы, которые выполняют проект, при этом могут быть задействованы конкретные люди на како-е-то время,но для конкретного проекта это тоже не принципиально.

А когда мы переходим к портфелю проектов – к мультипроектному управлению – то это:

• Во-первых, много проектов, а во-вторых, мы рабо-таем в рамках организации. То есть, для того что-бы по всему портфелю проектов у нас не было кас-совых разрывов, финансы проекта должны быть связаны с финансами всей организации

• Дальше – процессы должны быть связаны с про-цессами системы. В проектных примерах по ин-жинирингу, например, где в проекте надо закупить оборудование за рубежом – это переходит в отдел закупки, где отдел закупки работает уже как функ-циональная система, собирает заказы, отправляет, получает, разбивает по проектам

• Люди, то есть управление пулом материально-тру-довых ресурсов. Люди, которые выделяются под проекты, могут перекидываться между различ-ными проектами компании

– 131 –


• Главное – цели проекта должны быть синхро-низированы со стратегическим управлением в компании.

В случае мультипроектного управления, проект-ный треугольник превращается в проектную пира-миду, у него появляется еще одна ограничивающая вершина – ограничение по стратегии управления.

Роль стратегии в реализации проектов

Расшифрую, что это значит, чтобы было понятно.

Когда мы говорим о крупных/средних компани-ях, которые занимают ведущие позиции на рынке, то у них, естественно, есть стратегия (понимание того, куда они бегут, зачем они это делают, и что они будут делать).

Из чего складывается стратегия?• Первое – это требования, ожидания. Инвесторы,

директора эти требования/ожидания формулиру-ют

• Дальше – это возможности, угрозы рынка, каки-е-то идеи

• И, естественно, накачка стратегическими инве-стициями.

В дальнейшем, согласно сформированной страте-гии, собирается портфель проектов. Это – область деятельности стратегического комитета. Именно здесь происходит синхронизация портфелей с общей страте-гией. Это очень важно, и топ-менеджеры много време-ни тратят на решение этих вопросов. Даже если убрать

все политические составляющие – почему этот или дру-гой проект должен жить, и оставить именно идеологи-ческую составляющую пользы для предприятия,все равно на синхронизацию проектов уходит очень много времени. Потому что ресурсы всегда ограничены.

Дальше – область деятельности офиса управления проектами. Причем целью проектного офиса являет-ся не только реализация проектов портфеля, но еще и получение на выходе из проекта стратегических активов – их по-разному можно называть, главное, проектный офис отвечает за то,что компания на вы-ходе из портфеля проектов получит какие-то плюсы, которые сможет использовать в дальнейшем.

Также важной составляющей деятельности про-ектного офиса является так называемая «Внутрен-няя среда» – инфраструктура проектов, ресурсы, взаимоотношения между ними и так далее. Здесь проектный офис регулирует, как им надо интегриро-ваться, балансировать с процессами организации и т.д.

И, как вывод, применение проектных подходов позволяет максимизировать количество успешных проектов и сократить время выполнения этих про-ектов.

Небольшое отступление. На одной из конференций по проектному управлению выступали люди и говори-ли о том, что в проектах всегда ограничены ресурсы и т.д. И тут один дедушка встал и говорит: вы знаете, а я однажды работал в проекте, где не было ограничений в ресурсах. Все современные проджект-менеджеры, ко-нечно, удивились, спрашивают – «Как так, что за про-ект?» А он говорит – «Бомбу ядерную мы делали». Так что из всех правил есть исключения, конечно. Зато там стоит вопрос сроков и голов.

Задачи проектного офиса при реализации проектов.

Синхронизация портфеля проектов с производственными мощностями

• При управлении деятельностью очень важно по-нимать, какие у портфеля проектов есть ограни-чения

– 132 –


• В соответствии с этим надо думать, как должны быть распределены производственные мощно-сти

• И, исходя из этого соотношения, принимать реше-ния.

— Во-первых, надо балансировать. Может быть, у нас проектов больше, чем мощностей. Может быть, наоборот. И это – большие, решающие проблемы.

— Кроме балансировки, есть более существен-ные вещи, которыми тоже должны занимать-ся организации. Это такие вещи, как отказ от неправильных проектов. То есть те проекты, которые не вписываются в структуру, не согла-суются с целями – с ними надо что-то делать. Лучше даже закрывать, невзирая на то, что туда уже вложено большое количество ресур-сов, финансов, ну и просто жалко.

— Дальше – обеспечение эффективности про-изводственных ресурсов. Здесь можно при-вести пример, что ключевые специалисты по очень узким областям (уникальные в своем роде), например, архитекторы систем или функциональные архитекторы, не должны делать все рутинные операции, а желательно выделять их на ключевые точки постановки задачи и контроля над правильностью выпол-нения. А младшему персоналу передавать не-посредственное выполнение работ.

— То же самое с оборудованием. Оборудование тоже надо эффективно использовать. Не очень хорошо, конечно, называть людей ресур-сами и ставить их в один ряд с оборудованием, но так принято в проектном сленге. Поэтому – при некотором уровне абстракции такое срав-нение можно делать.

— Дальше – балансировка и устранение огра-ничений. Если можно расширить узкие огра-ничения по производственным мощностям, то это дает возможность организации делать больший объем. Зачастую организации к этому стремятся.

Задачи проектного офиса при реализации проектов.

Обеспечение ритмичности

Дальше по ритмичности. Ритмичность – это борьба с инертностью. Очень часто бывает, что проект идет-и-дет-идет, а потом он «засыпает». Может быть, у заказ-чика что-то случилось, еще что-то и остается только какое-то вялое движение.

Поэтому ритмичность – вещь важная. Это вопрос регулярного продвижения вперед.

Обеспечение ритмичности. Как это делается на практике?

Задается некий ритм каждого проекта, то есть:• регулярные проектные статусы – статусы могут

быть внутренние• если это трудоемкое производство, то это регу-

лярные проектные совещания внутри компании и проектные совещания с заказчиком.

Главное, чтобы они были четкие, с повестками, с ре-зультатами и оповещением по проведению, с конкрет-ными принятыми решениями и движением вперед, тогда это задает ритм, тогда это задает правильный настрой и понимание у команды, куда двигаться, какие конкретные оперативные задачи надо решить, и как они связаны с целями конкретного проекта.

– 133 –


Когда мы говорим о портфеле, то очень полезная и правильная вещь – это планерки, на которых участву-ют все руководители проектов, руководители отделов. На этих планерках обозначают текущие приоритеты, смотрят, какое движение вперед, определяют, где что-то пробуксовывает, где есть какие-то конфлик-ты, проблемы, где что надо решать, возможно, где-то расширить ограничения.

Дестабилизация проектной системы по аспектам.

Что дестабилизирует проектную систему? От чего она вообще зависит? Мы говорили про получение зака-зов, про выполнение проектов, про ресурсы и финансы в организации. Теперь конкретно, что дестабилизиру-ет систему по этим аспектам. Основные примеры.

• Со стороны заказов: — Изменения на рынке заказчиков. Простой

пример – кризис. Кризис пришел – все, бу-бух! — Неопределенность спроса. Что-то изменяет-

ся, происходит. Неясность.• Со стороны проекта:

— Изменение ситуации у заказчика. Крайний случай – у заказчика меняется руководство или собственники. Как следствие, рестарт на всех проектах этого заказчика

— Изменение параметров проектов. В нашей предметной области – это заказчик говорит: «Не, ну как же, у системы еще надо чтобы вот это тоже работало. Это тоже должно быть в рамках проекта». Или, например, дедлайн по срокам сдвигается (приближается). Или из-меняются сами процессы у заказчика, может быть, параметры взаимодействия этих процес-сов («однако за время пути собачка могла под-расти»)

• Со стороны внутренней работы — Взросление персонала. Такое всегда происхо-

дит. Люди набираются опыта, знаний, навыков — Изменения в самой компании. Компания мо-

жет переходить из стадии «Детство» в стадию «Зрелость» – и так далее по циклу Адизеса, по

жизненному циклу компаний. И это данность, компания изменяется, ее структура может ра-сти, уровни управления изменяются, все меня-ется

— Изменения на рынке труда. Когда мы говорим о трудоемком производстве, ситуация на рынке труда очень важна.

Разберу некоторые проблемные ситуации по ка-ждому из аспектов и постараюсь дать некоторые реко-мендации по каждому из них:

Рекомендации для стабилизации системы при проблемах с заказами

Первый вариант:• Ситуация

— Первое – системный или надсистемный кризис приводит к отсутствию заказов

— Либо второе – высококонкурентный рынок с узкой воронкой продаж, слабыми технология-ми продаж приводит к непонятному проценту «выстрела заказов». То есть, мы не можем по-нять, какой у нас будет портфель по заказам в ближайшее время.

• Рекомендации — Спасти положение может укрепление репута-

ции компании, — или получение ею некоторой рыночной силы

для привлечения заказов.• Следствие

— Это позволит организовать поток обраще-ний, соответствующий деятельности компа-нии, даст возможность компании выбирать «правильные» проекты и работать «на пото-ке». То есть, компания сможет нормально суще-ствовать.

Второй вариант:• Ситуация

— Несфокусированный портфель заказов. Зака-зы не соответствуют тематике и техноло-гиям. Взяли с рынка все что есть, пытаемся делать, но структура компании, люди и их ком-

– 134 –


петенции не соответствуют принятым заказам. Ситуация напоминает «тушение пожаров»

• Рекомендации — Необходимо «фильтровать» проекты, отказы-

ваться от неправильных проектов. На прак-тике можно сказать, что это очень тяжело сде-лать. Кажется, что каждый проект – именно он хороший, именно этот заказчик – правильный. Но это надо обязательно делать. Надо насту-пить на горло собственной песне.

• Следствие — Отказ от «неправильных» проектов высвобож-

дает ресурсы.

Третий вариант:• Ситуация:

— Несбалансированные годовые планы загрузки мощностей и неуправляемое заполнение зака-зами годового тематического плана приводит к тому, что заказы не соответствуют плановой мощности по компетенциям.

• Рекомендации — Балансировка планов, заказов и мощностей — Работы со свободной датой окончания — Возможность привлечения субподряда. Дол-

жен быть пул наработанных подрядчиков, с ко-торыми уже организована работа и все эти во-просы «притирок» не будут «съедать» большое количество времени

• Следствие — Гармонизация плановой загрузки

Четвертый вариант• Ситуация:

— Oversale. Набрали заказов на порядок боль-ше, чем можно выполнить.

• Рекомендации — Здесь важно уметь остановиться и сказать

себе «Всех денег не заработаешь», а если возь-мешь больше, чем можешь сделать, то явно «порвешься».

• Следствие — «не порвешься».

Рекомендации для стабилизации системы при проблемах с портфелем проектов

и ресурсов


— Не хватает «выстреливших» заказов, которые перешли в конкретные договоры. Ресурсы не-дозагружены.

• Рекомендации — Перераспределить ресурсы на другие виды

деятельности. Занять их внутренними задача-ми или обучением

— Или, к сожалению, сократить персонал• Следствие

— Минимизация простоев — Минимизация затрат

Второй вариант (ситуация обратная тому, что было в первом варианте):

• Ситуация — Портфель проектов не обеспечен ресурсами — Несоответствие компетенций — Нет кадровых резервов — Объем сверхрисковых проектов>20% от всего

портфеля — Нет временных резервов в проектах — Не выстроена соответствующая проектам

структура команды — Слабая «тасуемость колод» проектов и персо-

нала (нет возможности перекидывать людей с проекта на проект)

— Все это вызывает невыполнение задач вовре-мя, потерю рентабельности, срывы сроков про-екта.

• Рекомендации — Типизировать проекты — Структурировать проектные команды — Выстраивать однотипные проекты в очередь,

ходить по этим проектам одной командой — Накапливать и повторно применять знания — По каждому действию получать несколько ре-

зультатов: один «выстрел» (один проект) – два результата

— Планировать резервы• Следствие

— Соблюдение сроков проектов портфеля

Третий вариант• Ситуация

— «Прогиб» на имиджевых проектах. Взяли, должны сделать во что бы то ни стало. В ре-зультате происходит увеличение рамок проек-та без дополнительного финансирования

– 135 –


• Рекомендации

— Получить альтернативу. Если будет альтер-натива одного имиджевого проекта другому имиджевому проекту, то тогда проще решиться на более радикальные действия

• Следствие

— Возможность выбора

Четвертый вариант:

— Ситуация

— Перегруз специалистов

— Уход специалистов на «зеленую лужайку» – это частая история во всех видах бизнеса, когда че-ловек просто заработался, сгорел, устал, хочет отдохнуть. Работать на окладе, получать фик-сированные цифры. Это обычная история. Это данность

— Уход экспертов, желающих «свободу творче-ства при максимальном окладе»

— «Корона» у специалистов. Люди после прохож-дения проектов не желают браться за рутин-ную работу

— Долгая подготовка специалистов и руководи-телей проектов

— Это все обычные кадровые проблемы, кото-рые существовали и 50 лет назад, и будут суще-ствовать и дальше, во всех странах и везде.

• Рекомендации

— Обеспечение возможности карьеры и про-фессионального роста

— Соблюдение принципа, который часто приме-няется в консалтинговых компаниях, «вверх или в сторону»

• Следствие

— Достижение кадровой стабильности – это один из существенных аспектов трудоемкого производства, над которым все работают. На этот вопрос всегда тратится наибольшее коли-чество и нервов, и времени.

Рекомендации для стабилизации системы при проблемах с финансами

Первый вариант• Ситуация

— Получение большого процента низкооплачи-ваемых или высокорискованных заказов в общем портфеле проектов приводит к низкой или отрицательной рентабельности проектов

• Рекомендации — Стандартизация проектов. Если проекты

стандартизированы, то возникает большая на-работка, проще делать

— Навыки персонала, соответствующие требова-ниям проекта. Опять же, стандартизация помо-гает.

• Следствие — Управляемая рентабельность

Второй вариант• Ситуация

— Нетехнологичность, которая вызывает низ-кую рентабельность проектной деятельности

• Рекомендации — Технологии надо нарабатывать — Структура проектных команд и рычаг. Под ры-

чагом подразумевается соотношение старшего персонала к младшему. Рутинная работа отда-ется младшему персоналу, младший персо-нал меньше стоит, зато у них есть силы и жела-ние двигаться, развиваться

• Следствие — Управляемая рентабельность

Третий вариант• Ситуация

— Неравномерность и задержка платежей приве-ла к кассовым разрывам в финансовом состо-янии организации

• Рекомендации — Резервы или возможность короткого креди-

тования — Перекрытие разрывов потоком по стабиль-

ным видам деятельности• Следствие

— Закрытие кассовых разрывов

Четвертый вариант• Ситуация

— Завал проектов приводит к отрицательной рентабельности деятельности

• Рекомендации — Уменьшать процент высокорискованных про-

ектов — Выходить из проекта, если совсем плохо

– 136 –


• Следствие — Положительная рентабельность

Пятый вариант• Ситуация

— «Псевдовылезание» за счет «проедания аван-сов». В результате, та самая пирамида долгов, в которую «сваливается» компания. Здесь надо мониторить ситуацию, чтобы этого не происхо-дило

• Рекомендации — Управление рентабельностью каждого проекта — Управление денежным потоком

• Следствие — Положительная рентабельность.

Рекомендации для стабилизации системы при проблемах со стратегией


— Заказы не соответствуют профилю компа-нии, соответственно, нет сфокусированного накопления клиентского актива

• Рекомендации — Либо специализироваться на конкретике — Либо увеличивать масштаб и «всеядность»

организации• Следствие

— Конкурентные преимущества либо по модели «фермеров», либо по модели «охотников»

Второй вариант:• Ситуация

— Нет общей, объединяющей идеи, лидера. Разо-бщенность команды

• Рекомендации — Объединяющая идея, личность — Воля к победе — Регулярное достижение результатов, чтобы

это были не просто слова, а конкретные дей-ствия, подкрепленные результатами

• Следствие — Организационная общность, стиль и согласие

– 137 –

Si vis pacem, para bellum. Досудебная подготовка и защита интересов внедренца в суде

Артур АбеленцевРуководитель проектов, заместитель генерального директора ООО «АРТ саТерра»

От ведущего: Сейчас, как я понимаю, мы будем разговаривать о том, что надо задумываться над воз-можными проблемами заранее. Потому что если мы задумываемся о возможных проблемах заранее, мы, тем самым, уменьшаем риски в конце.

От докладчика: В любом деле такое утверждение верно. Даже если наш бизнес взять, если на ТЗ схалту-рил, то получаешь проблему потом. Здесь ровно такая же история, коллеги, готовиться надо не для того, чтобы в суд ходить, а для того, чтобы как раз в него не ходить.

Тема доклада не очень характерная для нашей кон-ференции. Года два назад я бы сказал, что вообще-то это нас не должно касаться. Это все где-то в другом мире происходит. А вот в начале 2012 года выяснилось, что нас это очень даже и касается.

Личный опыт

Соответственно, за период 2012-2013 года – шесть исков на общую сумму чуть больше 13 миллионов ру-блей. Вся статистика перед вами.

Почему я предложил организаторам такой до-клад?

Потому что я в процессе подготовки ко всем этим мероприятиям начал изучать опыт старших братьев. Ну, то есть, в буквальном смысле – первая половина первой страницы списка франчайзи. Я смотрел, какие

решения судов по ним были. Какие были суды. Ока-залось, что даже «старшие братья» допускают ошиб-ки. И мне подумалось, что надо вам тоже дать этот «parabellum», для того, чтобы не «вляпаться» в каку-ю-нибудь историю.

Нормативная база

Давайте с нормативной базы начнем.

По нашей деятельности, наши договоры между юр. лицами регулируются Гражданским кодексом.

Как только мы идем в суд – надо начинать читать Арбитражный процессуальный кодекс.

Что надо прочитать в Гражданском кодексе?

Я зачитывать не буду, на этом слайде все написа-но. Прочитать советую. Кто не читал, тот для себя мно-го интересного откроет.

Выполнение этапа

Теперь к делу. Классика жанра – на этом слайде изо-бражено, как выполняется этап по шкале времени.

– 138 –


Где-то в начале заказчик платит аванс, если это предусмотрено договором, соответственно исполни-тель начинает выполнять этап.

Заказчик делает что-то свое, предоставляет ин-формацию, доступ, людей… Что-то еще, что нужно по теме услуги. А исполнитель, соответственно, пытает-ся достичь результата.

После того как услуги по этапу оказаны, исполни-тель передает заказчику результаты оказанных услуг с бухгалтерскими документами. Дальше у нас идет этап приемки. После чего акт подписан и где-то в конце мы получаем оставшиеся деньги.

Это – классическая схема, любую нашу проектную деятельность можно свести к такой схеме отношений.

Проблемы в ходе выполнения этапа

Соответственно, какие проблемы у нас могут воз-никать?

Например, в самом начале не был выплачен аванс, хотя он был предусмотрен договором.

Или, к примеру, в ходе выполнения этапа заказчик начал забывать о договоренностях о предоставле-нии информации, о каких-то промежуточных согласо-ваниях, которые тоже бывают важны.

Дальше – на этапе приемки заказчик отказыва-ется от приемки. Отказы бывают мотивированные и немотивированные.

Или, все хорошо сложилось, акты подписали, и по каким-то причинам заказчик оплату задерживает или ее производить не хочет.

А также – в любой момент времени заказчик мо-жет отказаться от исполнения договора. Причем, у нас Гражданский кодекс в этом смысле целиком и полностью на стороне заказчика. То есть, чтобы вы ни написали в договоре, какие бы вы условия там ни обозначили, заказчик в любой момент имеет право от исполнения договора отказаться. С разными для себя последствиями, но тем не менее.

Техника безопасности (в тексте договора)

Соответственно, у нас есть перечень проблем, и я для себя сформулировал некоторую технику безопас-ности, которую полезно выполнять для того, чтобы либо минимизировать вероятность наступления этой проблемы, либо, чтобы у нас были какие-то аргументы на случай, если все равно случилось.

• Начнем по риску отказа от оплаты аванса. — Первое, что всем советую: по возможности,

убирайте из договора все формулировки о том, что оплачивать услуги надо по выставленному исполнителю счету. Почему лучше убрать? Вот, у вас хорошие отношения с заказчиком, вы счет напечатали, у руководителя подписали, счет принесли, Иван Ивановичу вручили. Все хоро-шо, все улыбаются, только деньги почему-то не платят. Потом вы идете в суд и начинаете гово-рить: «А вот я счет Ивану Ивановичу вручил». А Иван Иванович и говорит: «Нет, не помню, мне никто ничего не вручал». Ну и судья будет на вас смотреть и говорить: «А как вы докажете, что вы Ивану Ивановичу что-то там вручали?» Вот для того, чтобы убрать ситуацию с необхо-димостью там что-то сдавать под подпись и так далее – убирайте слово «Счет» из договоров. Пусть платят на основании договора (в слу-

– 139 –

Si vis pacem, para bellum.Артур Абеленцев Досудебная подготовка и защита интересов внедренца в суде

чае с авансами) или счета-фактуры (оплата по подписанным актам).

— Далее – что надо включить обязательно. Пря-мым текстом обязательно включайте, что вы имеете право работы останавливать в случае, если заказчик нарушает условия оплаты. Не об-щая формулировка «В случае невыполнения ус-ловий договора», а конкретно: нет денег – нет работы.

— Следующий момент, тоже очень важный. Если у вас в условиях договора написано, что вы начи-наете работу после аванса, то, в случае, когда нет аванса, работу не начинайте. Потому что, если нет аванса, а работу вы начали, то судья на это дело будет смотреть так – раз вы начали ра-боту без аванса, значит, вы на это согласились. А если вы с этим согласились, а потом начали по каким-то причинам работы останавливать – то это уже ваш отказ от исполнения договора, причем, необоснованный. Это плохо.

• Следующий набор проблем – это все, что в ходе выполнения возникает. Как с такими проблема-ми бороться? Четкие формулировки в договоре, чего вы хотите от Заказчика.

— Если вам нужен удаленный доступ, вы при-выкли с ним работать, то пишите это в договор, чтобы потом с удивлением не обнаруживать, что заказчик говорит вам – «Ходите, пожалуй-ста, ко мне в офис. Я знать ничего не знаю об удаленном доступе».

— Что касается предоставления информации – опять же, не советую ограничиваться каки-ми-то общими формулировками, наподобие «Заказчик предоставляет всю необходимую информацию». Вот вам, допустим, на этапе обучения нужна одна какая-то информация от заказчика или доступ к каким-то ресурсам, а на этапе переноса остатков – совсем другое. Где вы в договоре этапы формулируете, там же крайне полезно по каждому этапу хотя бы в общем виде обозначить, что вы будете от за-казчика ждать.

— Если у вас в проекте есть моменты получения от заказчика информации, от которой зави-сит качество услуг или сроки выполнения, вот эти вещи тоже надо сразу вписывать в до-говор, по возможности.

— Если на этапе подписания договора такой воз-можности нет, обозначайте, что вы это допол-нительным соглашением будете делать по-том. Иначе у вас могут быть проблемы.

• Отказ от оплаты принятых услуг. — опять же – выкидываем из договора слова

про счет — и четко обозначаем, когда, через сколько

дней после подписания акта у нас должна быть произведена оплата.

Техника безопасности по отказу от приемки и по отказу от договора

(в тексте договора)

Отдельно вынес два самых тяжелых случая. • Первый из них – отказ от договора. Мы потом от-

дельно еще на нем остановимся. Что я в практике подсмотрел?

— Есть такая компания – консультанты такие се-рьезные. Вот эти товарищи консультанты, не стесняясь, очень подробно в договор вписы-вают, что, если заказчики расторгают договор по собственной инициативе, то сумма аванса остается у исполнителя в качестве фактиче-ски понесенных затрат и заказчик с этим за-ранее соглашается.

— Еще один совет. Если вы работаете с заказчиком и видите, что у вас есть угроза расторжения – заказчик потерял интерес к проекту, потерял интерес к вам, вдруг почему-то решил, что он ошибся и хотел совсем не то, на что вы уже по-тратили свое время, силы и деньги, то переда-вайте заказчику закрывающие документы. Почему их надо передать? Согласно существу-ющей практике, заказчик лишается права отказа от договора после передачи результа-тов. То есть, даже если вы все не доделали, но результат передали – все, вы лишили заказчика возможности ваш с ним договор расторгнуть.

• Тяжелый случай – отказ от приемки. Что на этапе подписания договора необходимо предусматри-вать?

— Первое – это четко обозначать требования к результатам оказанных услуг. Требования к результатам должны быть измеримые. На-пример, вы пишете техническое задание. Не надо писать просто в результатах этапа – «на-писанное ТЗ». Вы по такому описанию можете очень долго сдавать этот результат. Нужна хоть какая-то конкретика. Как пример: «ТЗ, состоящее из таких-то разделов по такой-то предметной области». Все, что знаете на мо-мент подготовки договора, – надо вписать.

– 140 –


— Второй важный момент – результаты ваших услуг должны быть в пределах вашего кон-троля.Мы сейчас в конкурсе одном участвуем. Там Заказчик в проекте договора, в конкурсной документации написал, что исполнитель дол-жен обеспечить заказчику 20% сокращение персонала по результатам реализации систе-мы. Но дело в том, что сокращение персонала не находится в вашей власти. Заказчик захотел – уволил. А не захотел – не уволил. Вы не по-лучили свои деньги. Надо переформулировать такое утверждение. Допустим: «Разработанные регламенты процессной модели «как будет» должны предусматривать плановое сокра-щение на 20% по сравнению с моделью «как есть»». Вот это уже в вашей власти. Вы можете это в модели обеспечить.

• Далее – Исчерпывающий перечень документа-ции. В договор надо вписать – по завершении каж-дого этапа мы сдаем:

— акт (2 экземпляра); — счет-фактуру (кому полагается); — результаты оказанных услуг в виде комплек-

та документации, предусмотренной этапом.

Все это нужно для того, чтобы у заказчика не было соблазна отказывать вам в приемке потому, что вы, на его взгляд, ему чего-то не додали.

• Крайне важный момент – определить порядок передачи! Если вы приходите и просто кладете заказчику на стол материалы – считайте, что пере-дача у вас не состоялась. Вариантов два:

— Надежный, но долгий. Почта России, заказное письмо с уведомлением и описью вложения;

— Вариант более красивый и технологичный – это непосредственнов договоре обозначить фамилию и должность тех ответственных лиц, которые уполномочены сторонами для приемки и передачи результатов. Хотя бы на рассмотрение, даже не на подписание актов. И подписывать у них передаточное письмо, в ко-тором вы описываете, что конкретно, к какому этапу и договору вы передаете.

Два последних пункта очень важных:• Мотивированный отказ. Когда я изучал дого-

воры коллег, то у всех в договорах есть слова про мотивированный отказ. Но только в двух догово-рах я встретил четкое определение того, что такое «мотивированный отказ». Например, вы внедря-ете бухучет, а у заказчика что-то в бизнесе поме-нялось. Соответственно, на момент сдачи заказчик вам говорит: «А мне сейчас уже так не нужно, мне уже сейчас по-другому нужно». Это мотивирован-ный отказ, по-вашему, или нет? Соответственно, в договор лучше прописать, что мотивированный отказ – это обнаруженное явное несоответствие

результатов оказанных услуг положениям дого-вора и приложений к нему. Тем самым мы сразу от-секли фантазии заказчика на тему того, что такое мотивированный отказ.

• Сроки предъявления мотивированного отказа. Как ситуация видится со стороны заказчика? Принес исполнитель «макулатуру». Положил ее и говорит – «проверь и подпиши акт». Сотрудник заказчика может три месяца смотреть или не смо-треть эту документацию – зарплату он все равно по-лучает. И он, в этом смысле, достаточно комфортно себя чувствует. А у вас ситуация другая: нет подпи-санного акта – нет денег. Нет денег – нет возмож-ности выплатить зарплату своим сотрудникам. Некоторые сотрудники заказчиков ведут себя как летчики гражданских самолетов, которым вдруг парашюты выдали. Они думают: «Если что-нибудь сломается, я выпрыгну, и все будет хорошо». Пара-шютов их надо лишать, потому что иначе вы не бу-дете достигать цели проекта.

Техника безопасности в ходе выполнения

Будем считать, что мы на этапе договора технику безопасности выполнили, все пункты предусмотрели. Теперь рассмотрим технику безопасности в ходе вы-полнения.

• Первое – необходимо обеспечить материальные свидетельства по всем вехам того, что в догово-ре происходит, согласно схеме выполнения этапа, о которой говорили выше. Почему материальные свидетельства? Суд не интересуют рассказы граж-дан о том, кто, куда, как ходил и кто чем занимал-ся. Суд интересует наличие материального свиде-тельства – бумага с печатью. Про доказательства подробнее расскажу еще чуть позже.

• Второе: как только вы начинаете испытывать более-менее серьезные затруднения в работе – это не повод для скандала, но это повод создать материальный след того, что вы эту проблему об-наружили и заказчика о ней проинформировали. Вот здесь можно смело «Почту России» использо-вать. Допустим, есть у вас этап переноса остатков.

– 141 –


Сделали вовремя – успели запуститься в январе. Не сделали – не успели. Важный момент? Важный. Заказчик тянет с предоставлением исходной базы для переноса. Поставьте его в известность о том, что он вообще срывает весь проект из-за того, что тянет с базой. Причем поставьте его в извест-ность об этом через Почту России.

Какие точки фиксируем: • начало этапа, • конец этапа, • все сложные запросы, от которых зависит ка-

чество. К примеру, вы разрабатываете сложный управленческий отчет, Вам заказчик должен его форму и формулы для расчета передать. Вот полу-чаете форму и формулы – оформите протоколом, что вы их не нашли на столе (вдруг потом ока-жется, что заказчик совсем другое имел в виду), а именно это заказчик вам и передал.

Не удалось договориться. Последовательность действий

Соблюдаем технику безопасности. Что-то пошло не так, не удалось договориться. Запускаем досудебный порядок.

Досудебный порядок – это письмо, в котором на-писано о претензиях в порядке до арбитражного ре-гулирования. В этом письме вы заказчику сообщаете, что «В соответствии с договором (или в соответствии с приложением к договору), пункт такой-то, вы должны были сделать это и это – вы не сделали (или вы не за-платили). Прошу в срок до такого-то числа устранить допущенные нарушения. В противном случае мы бу-дем вынуждены обратиться в суд».

Многим может показаться, что, действуя таким об-разом, легко заработать имидж эдакого скандалиста. Мы про имидж позже поговорим. По опыту могу ска-зать, это надо делать.

Если после такого письма проблема устранена – от-лично. А если проблема не устранена?

По-хорошему, когда вы готовите претензию, у вас

на руках уже должно быть подготовленное исковое заявление. Если срок, обозначенный в претензии, прошел, отправляете иск стороне и в суд. Стеснять-ся никого не надо. К примеру, заказчик в этот момент исправляется и выполняет свои обязательства – вы всегда можете иск отозвать, не обязательно нужно до конца идти. Но! Здесь есть важный момент: не реа-гируйте на обещания «Ты иск отзови, а мы через два дня исправимся», потому что, если вы иск отозвали, то повторно по этому же поводу в суд обратиться не имеете права, вообще никогда нигде на территории Российской Федерации. Дождались выполнения иско-вых требований – отозвали иск, по-другому нельзя.

Вероятность проигрыша не рассматриваем, исхо-дим из того, что мы добросовестно исполняем обяза-тельства по договору и соблюдаем технику безопасно-сти.

Поход в суд. Когда мы будем ходить в суд? • Либо нас вызвали и мы ответчик. • Либо мы туда сами идем и мы истец• (есть еще вариант, когда мы третья сторона, на-

пример – назначенный судом эксперт. Но это уже за рамками нашей беседы)

Лучше быть истцом. Почему?• Психологический момент – судья к истцу изна-

чально лучше относится (совсем немного, но тем не менее), потому что судья понимает – раз истец пошел в суд, с большой вероятностью его ответчик довел до этого.

• У истца есть выбор способа защиты права (истец выбирает, чего он хочет от ответчика). Пример – делаете 500 управленческих отчетов. Застряли на последних трех. Сдать из-за этого работу не мо-жете. Заказчик необходимой вам для исполнения информации не предоставляет. У вас выбор спо-соба защиты права. Вы можете ходатайствовать перед судом, чтобы он вам зачел стоимость за 497 отчетов, и вы расстались с заказчиком. Либо вы можете потребовать от заказчика предоставить эту информацию, доделать отчеты и закрыть акт на полную сумму. Понимаете, почему хорошо ист-цом быть?

– 142 –


Нет ущерба имиджу.

Советую в суд внедренцу не ходить.

Как судья видит ход дела? Это мы с вами понима-ем какие-то тонкости конфигурирования, мешающие находить взаимопонимание с заказчиком. Судья в этом не понимает ровным счетом ничего. Он до вас со стра-ховыми компаниями разбирался, а после вас кому-то трубы не того диаметра поставили. То, что в середине пришли внедренцы – ему вообще это неинтересно.

На что судья смотрит? Он смотрит на наличие доказательств по тем вехам, которые я на шкале вре-мени на одном из слайдов обозначил в самом начале. Толковый представитель из ваших рассказов соберет вот эту цепочку фактов и аргументов, которую смо-жет судье представить.

Человек, который приходит в суд за справедли-востью, обычно может сказать что-нибудь лишнее. У меня был один случай, после которого в суд я лично ходить перестал, теперь только представители ходят.

У одного из наших заказчиков начались проблемы с руководством – раз в полгода там меняется генераль-ный директор, и, в связи с этим, проект уже железо-бетонно остановлен. Мы очередной этап завершили в апреле 2011 года. То есть, фактически, услуги оказа-ны, но, из-за многократной смены руководителя, до-кументы не подписаны.

В апреле 2012 года (год прошел) я вспоминаю о том, что этап завершен и неплохо было бы получить от заказчика стоимость этого этапа.

Как я сам в технике безопасности писал – Почтой России, передаточное письмо, акты, результаты ока-занных услуг. Ничего не дождались, мотивированного отказа нам никто не предоставил (они просто проигно-рировали передаточное письмо), в конце года выходим в суд.

С судьей начинаем ситуацию обсуждать, и я судье говорю – «Вы знаете, у нас год назад отключили тер-минальный доступ, мы целый год не могли работать, и вот, только через год сдали этап». Судья: «Так, интерес-но… У вас, значит, не было возможности услуги ока-зывать, а вы тут какие-то результаты сдаете?» Тут я понял, что я что-то лишнее сказал.

С тех пор я в суд не хожу и вам не советую.

Доказательства и доказывание

Давайте про доказательства.

Плохие доказательства.• Свидетельские показания. Есть такая иллю-

зия почему-то у многих, что сейчас мы вызо-вем 100 свидетелей и они в суде расскажут, ка-кие мы прикольные, что мы все закончили, и судья радостно крикнет: «Дорогой ты мой, ко-нечно же, ты прав! Сейчас мы тут всех накажем». Ничего подобного. За шесть исков нам не удовлет-ворили ни одного ходатайства о вызове свидете-лей. Причем, вызывали мы не своих сотрудников, мы вызывали сотрудников противной стороны. Несмотря на это судья сказала «Мне не интересно, что люди рассказывают. Все врут»

• Далее – Экспертиза по собственной инициативе. Был смешной случай в последнем деле. Когда от-ветчик привлек другого франчайзи и другой фран-чайзи пришел и сказал «Конечно, это нехорошие люди, они вас обманывают. Все не так, реализация задачи неправильная». Тут судья так обрадовалась «А, я поняла, вы хотите заплатить за экспертизу! А то вы приносите какие-то доказательства, а я же не поручала никому ничего делать. Вот, сейчас по-ручу, а вы заплатите». Я к чему это веду. Не надо ничего такого объяснительного приносить от третьей стороны, пока судья не поручит. То есть, пока нет поручения судьи, ее не интересует, что там говорит третья сторона

• Распечатки электронной почты. Что такое элек-тронная почта, если нет ЭЦП? Вы ни время, ни со-держимое не можете подтвердить.

• Еще момент – «У нас есть Устав проекта, а заказчик не выполняет его условия. Там указано распреде-ление рисков, и этот риск распределяется на заказ-чика». А представитель заказчика говорит – «А что, устав – это приложение к договору?» Если оказы-вается, что нет, то судья это отбрасывает. То есть, все, что не является приложением к договору (то есть, в договоре об этом не написано), не рас-сматривается в рамках дела.

– 143 –


Хорошие доказательства• Самое лучшее – бумаги подписанные уполномо-

ченными лицами обоих сторон. Причем тут важ-но каждое слово

— Бумаги – то есть, это не электронный вид, — подписанные – то есть, это не ваша распечат-

ка, оставленная на столе у заказчика, как ре-зультат совещания,

— уполномоченными лицами – не абы кем, а – • либо руководителем, который имеет право

без доверенности подписывать, • либо лицом, которое зафиксировано в до-

говоре, что имеет право эти бумаги подпи-сывать,

• либо лицо, на которое есть у вас копия до-веренности, что он это имеет право подпи-сывать.

Мы вот сейчас без всякого стеснения, когда начи-наются в крупных заказчиках совещания с уполномо-ченными лицами, то, если упоминания этих уполно-моченных лиц нет в договоре, мы с их руководителей всегда просим доверенность, о том, что организация этим уполномоченным лицам доверяет принимать оперативные решения.

Экспертиза. Вопросы эксперту

Предположим, суд по ходатайству одной из сторон назначил экспертизу. Когда это обычно происходит? Вы результаты сдали, а заказчик говорит «Это неваж-но. У меня мотивированный отказ, у вас что-то там не соответствует». Судья начинает это читать и пони-мает, что он ничего не понимает.

Когда судья не понимает что-то, он говорит «По-зову-ка я эксперта, который переведет мне то, что я не понимаю, с вашего языка на русский. И, в слу-чае чего, будет нести уголовную ответственность за заведомо ложную экспертизу» Когда судья такое ре-шение принимает, по АПК он должен сформулировать вопросы эксперту, но обычно это делают стороны.Неграмотные стороны формулируют вот такие вопросы, как показаны на слайде:

• «Обеспечивает ли выбранный Исполнителем спо-соб обращения к веб-сервису выполнение второго правила нормализации базы данных?» К примеру, эксперт выносит решение «Не обеспечивает». Су-дья читает и говорит «И что???» А может, он и не должен обеспечивать? А может, это вообще очень хорошо, что он этого не обеспечивает, понимаете? То есть, судья по ответам на такие вопросы не может сделать вывод о том, насколько услуги оказаны в соответствии с требованиями дого-вора.

Правильные вопросы на слайде тоже показаны:• Самый главный вопрос «Предусмотрены ли тре-

бования Заказчика условиями договора?» – сра-зу отбросили фантазии о том, что заказчик сам себе придумал.

• Второй вопрос: «Обнаруженные недостатки: зна-чимость (существенность), возможность устра-нения, затраты на устранение». Почему важно? В любой работе можно найти недостатки, но одно дело, когда вы построили домик и в него заходить даже опасно. А другое дело, если вы дом построи-ли, зайти можно, но в туалете одна плитка кафеля отвалилась. То есть, домом можно пользоваться. В таком случае, судья может выносить решение о том, что вам там не 100 рублей положено, а 99, на-пример. По крайней мере, вы не теряете всего.

• Далее – «Возникли ли отклонения/недостатки по вине Заказчика?» Внедряете бухучет, первый квартал прошел, опытная эксплуатация закончи-лась. Формируете отчетность. Баланс не сходится. Заказчик пишет отказ от принятия – как это так, баланс не сходится, что это за система бухучета? А эксперт изучает исходные данные, которые были предоставлены для переноса. Обнаруживается, что у заказчика баланс уже лет пять, как не схо-дится. То есть, ему нет повода сходиться, и вашей вины в этом нет.

Обеспечение доказательств

Практику обеспечения доказательств мы подсмо-трели у Microsoft.

– 144 –


Какая там была ситуация у Microsoft? Представи-тели Microsoft обнаружили, что в какой-то школе ис-пользуется нелицензионная Windows. По этому поводу Microsoft пишет письмо в школу: «Купите, все-таки, ли-цензионную Windows!».

Директор школы пишет в ответ: «Ребята, не могу – денег нет».

Microsoft обращается в суд с иском. Директор шко-лы получает по почте этот иск и определение. В шко-ле тут же дается команда стереть Windows, поставить Linux. И Microsoft в суде уже не сможет доказать, что школа чего-то нарушила в части использования ПО.

В АПК есть отдельная статья, которая так и называ-ется «Обеспечение доказательств». Эта статья о том, что если одна из сторон видит доказательство, которое находится в ведении другой стороны и есть риск унич-тожения или устранения этого доказательства, то эта сторона может обратиться к суду с ходатайством о том, чтобы суд выпустил отдельный исполнительный лист – поручение об обеспечении доказательств. И тогда вы с приставами пойдете на территорию заказчика, и там пристав (с привлечением соответствующих специали-стов) сделает то, что написано в исполнительном ли-сте, – скопирует БД, снимет логи подключений, и т.п.

Когда это можно применять? Вот вы, к примеру, технику безопасности нарушили, и начало проекта не отметили. Например, вы нигде не зафиксировали то, что вы ходили, работали, выполняли проект. Что у вас остается?

• У вас остается свидетельство людей, которые ви-дели, как вы ходили – оно не считается

• У вас остается копия базы данных – она тоже не считается

• У вас остаются логи, журнал регистрации – они тоже не считаются

• Что еще остается – написать такое ходатайство, где сказано, что результаты нашего труда, кото-рые подтверждают факт оказания услуг – они у за-казчика. Нам надо бы туда сходить и эту копию взять. Судья в этом случае может принять реше-ние отправить за этой копией приставов. Правда, он редко это делает – мы два раза подавали такое ходатайство, и только один раз оно было удовлет-ворено судом.

Компенсация понесенных затрат

Помните, про расторжение договора в самом нача-ле мы говорили, что это очень плохо. Почему плохо? Потому что в этом случае получить что-либо в качестве компенсации понесенных затрат будет крайне непро-сто. Рассматриваем вариант, когда договор расторгнут по инициативе заказчика (не в связи с нарушениями условий договора с вашей стороны). ГК при расторже-нии договора по инициативе заказчика (например, в связи с утратой интереса) предусматривает компенса-цию исполнителю фактически понесенных затрат. Но, чтобы эту компенсацию получать – необходимо дока-зать объем фактически понесенных затрат. Что та-кое фактически понесенные затраты в нашей деятель-ности? Это немножечко прямых затрат и большая доля накладных затрат. Какие вопросы возникнут у судьи, и будут поддержаны противоположной стороной?

• Зарплату сотрудников в качестве понесенных за-трат выставили. А как вы докажете, что Иванов все свое время (все свои 90 тысяч в месяц) тратил на то, чтобы работать именно в этом проекте? А если Иванов, к тому же, начальник отдела, то все понимают, что Иванов еще чем-то занимался. Зна-чит, не 90 тысяч. А сколько? Нельзя объективно определить. А если нельзя определить, значит, ноль. Понимаете юмор ситуации?

• Накладные расходы. Почему такая доля? Почему такая база разнесения? Почему такой способ раз-несения?

• Субподрядчики. Если это договор оказания ус-луг, предусмотрено ли договором привлечение субподрядчиков? Имели ли вы право делать это без согласования с Заказчиком?

• Самый важный момент – как арбитраж относится к фактически понесенным расходам. В практике арбитража к понесенным расходам относятся не начисленные, а фактически оплаченные рас-ходы (расходы определяются не по методу начис-ления, а по кассовому методу). Вот, например, вы с субподрядчиком акт о каких-то проделанных ра-ботах подписали. А суд говорит «Нет, ребята, пока с вашего расчетного счета денежка за это не ушла, вы ничего не понесли». То есть, даже если,напри-мер, ваш сотрудник Петров был в командировке и,

– 145 –


естественно, работал только на этот проект, но вы это пока что не оплатили – с очень большой веро-ятностью суд вам скажет: «Ребята, вы затрат пока не понесли. Мало ли, что у вас долг перед Петро-вым, и вы все равно его выплатите. Если на дату заседания не понесли – до свидания»

По теме фактически понесенных затрат достаточно большой объем моментов, которые возникают в этой истории – за 40 минут нельзя рассказать.

Выиграли. Что дальше?

Предположим, выиграли, прошли все инстанции и получили исполнительный лист.

Исполнительный лист – это такая команда специально обученным людям сделать то, что в ис-полнительном листе написано. Если в исполнитель-ном листе написано, что вам нужно вернуть деньги, то у вас есть два варианта:

• Вы идете в банк должника. Это быстро.• Либо – если вы не знаете, какой у должника банк

или там нет денег – вы идете к приставам, и пусть они с должником разбираются сами.

Ну и, соответственно, если выиграли, имеете пра-во на компенсацию затрат на услуги привлеченного юриста (если юрист наемный – не в штате).

Имиджевые последствия

• Сейчас крупные компании спрашивают в кон-курсной документации «были ли вы ответчиком? Почему? Чем закончилось?». Обратите внимание, их не интересует, были ли вы истцом.

• Ваш выигрыш в суде – это хороший сигнал для не-добросовестных контрагентов. В начале проекта можно упомянуть, что у нас вот такая процеду-ра, мы там судимся… Если вам начинают сразу объяснять, что вы скандалист и нехороший чело-век, – это сигнал.

• У нас есть заказчик, большая строительная ком-пания. Вот, несмотря на то, что мы дружим – все этапы, которые там проходят, я им сдаю Почтой России. Почему Почтой России? В какой-то момент они мне сказали «Мы это сейчас подписывать не будем». Я сказал «Ок, пускай почтой приходит. Мне спокойней». У нас с ними сейчас ситуация – мы им в феврале направили акт по этапу настройки конфигурирования. Они его не подписали. Мотив следующий – у них ИТ-отдел комплексно уволился, им проверить некем. Ну а я-то причем, что им про-верить некем? Мои десять дней уже давным-давно прошли. Но, поскольку у нас с ними хорошие отно-шения, я спокойно жду. Но если вдруг там поменя-ется руководитель, который скажет «А я чихать хотел, что вы там делали до того» – у меня уже го-това железобетонная база в арбитраж и за два заседания мы это дело закроем. Отношения при этом не портятся, то есть, это надо делать.

Теория – структура судебной власти в РФ

Немножко теории – структура судебной власти. У нас есть такие суды:

Когда спорят юридические лица – они «клиенты» арбитражных судов.

Появился специальный суд по интеллектуальным правам. Мы, наверное, в нашей работе его не сильно ка-саемся. А вот Microsoft, разработчики софта – они будут туда ходить в случае чего.

Есть еще третейский суд, но это экзотика. Причем, экзотика дорогая. Туда ходить не надо.

– 146 –


Арбитражный суд – самый автоматизированный

У нас арбитражный суд – он самый крутой с точки зрения автоматизации (без преувеличения).

Абсолютно все дела, которые не под грифом «Се-кретно» – вы можете здесь прочитать.

Абсолютно весь документооборот с судом вы мо-жете делать в электронном виде. Мы за последние три иска даже оригиналы документов в суде не пока-зывали, понимаете? Мы скан отправили – противопо-ложная сторона вопросов по документу не заявила. Су-дье не надо смотреть на оригинал. Это очень удобно.

Опыт коллег.

Заходим на сайт kad.arbitr.ru. В участники дела за-биваем интересующие нас названия (примеры на слай-де). Нажимаем кнопку «Найти».

Самое полезное там – полные решения. Судья объ-ясняет, почему он это доказательство принял, а это нет. Это очень полезная вещь, читайте на ночь, вместо сериалов J

– 147 –

Организация жесткого контроля при внедрении информационных систем

Алексей ПатюковКонсультант по постановке и организации учета. Ведущий рубрики «ФРИЛАНС: Инструкция по применению»

От ведущего: Алексей, объясни, жесткий кон-троль – это как? Прямо ногами?

От докладчика: Прострелить коленку, в первую очередь. А по-хорошему, то, что я понимаю под тер-мином «жесткий контроль» – это тотальная слежка за работой пользователей на провальных объектах учета. Зачем? Первый момент – я не внедренческая фирма. Я – фрилансер. Если я проект не закрою и денег не по-лучу за три-четыре месяца работы на этом проекте, то прибыль за год у меня выходит в ноль. Соответствен-но, моя задача – процесс внедрения организовать так, чтобы при запуске у меня не было сбоев. Я стараюсь перед началом запуска убрать все факторы риска. Со-ответственно, я провожу анализ. Работаю с владель-цами бизнеса. Ставлю на заметку провальные зоны доступа в компании. И эти зоны ставлю на тотальный контроль. Внедряю наблюдателей на проекте, которые там с секундомером работают. И внедряю администра-торов. Основная задача – убрать все риски и по факту проекта получить деньги.

Я – фрилансер. На своих проектах финансовый во-прос я обязан полностью закрывать сам. Работаю с компаниями, в которых до 50 рабочих мест. Как прави-ло, это спокойный управляемый проект на одного че-ловека. По обороту – у контор, с которыми я работаю, годовой оборот бывает до 2-х миллиардов.

Я работаю в основном с фирмами, где владелец является создателем этого бизнеса, потому что там очень много эмоциональных включений владельца в бизнес, и, следовательно, мотивация очень силь-ная. У тех фирм, где бизнес используется просто как дойная корова – другие варианты. С ними сложнее работать.

Основные блоки доклада

Их четыре:• Экспресс-анализ и диагностика компании• Работа с дирекцией и владельцами бизнеса• Работа с сотрудниками• Запуск системы

Вопросы разработки я не рассматриваю. Я не зани-маюсь разработкой. Я занимаюсь запуском. Разраба-тывать на моих проектах может франчайзи, кто-то из подрядчиков или сами программисты заказчика. Мое дело – запустить систему без сбоя, к назначенному сро-ку. Соответственно, весь момент разработки отсюда убираем.

Поскольку блока четыре, это блоки по элементам работы. Они итеративно могут повторяться, превра-щаться в какие-то циклы, в зависимости от типа ком-пании, наличия там определенной структуры владель-цев, наличия «неприкасаемых», ну и прочих вариантов. Каждый проект индивидуален. И вот тут у нас больше работает творчество.

(От ведущего) Больше похоже, что ты человек, на-водящий шорох.

Реально так. Потому что без этого, в конторах, в ко-торых провален учет, просто не сделать ничего. Поэто-му я спокойно навожу шорох эмоциональный, спокойно могу давить на пользователей, и мне это разрешается владельцами бизнеса. Если пользователям это не нра-вится, они идут к владельцу, жалуются на меня. Но вла-делец бизнеса создает мне крышу, успокаивает пользо-вателей: «Ребята, этот человек переживает за проект, поймите его». За прикрытием меня и моего поведения по проекту полностью отвечает владелец бизнеса.

Первый этап. Экспресс-анализ (диагностика)

На этом этапе я попадаю в компанию, и я ничего о ней не знаю.

– 148 –


Мои задачи:• Собрать сведения об общем отражаемом доку-

ментообороте в системе. В семерке это Базопузо-мер. В восьмерке – свои средства. Если работаете – знаете. Собираем все эти сведения. Группируем по видам документов. Группируем по блокам учета.

• Оценить временной лаг ввода документов. Что это такое? Оценивается расхождение по времени между попаданием документа в компанию, допу-стим, на физическом носителе (бумаге), и разме-щением его в информационной системе. Это один из самых жестких показателей. А как его изме-рить? По логам. И в семерке, и в восьмерке они от-ражаются. Простейший пример: когда я вижу, что у меня документ отражен 23 февраля, но по логам дата, допустим, 9 мая – я сразу высчитываю, что лаг расхождения почти три месяца. Как вы думае-те, при таком способе ввода информации насколь-ко корректна отчетность? Соответственно – я вижу блок учета, где лаг максимальный, и ставлю на ка-рандаш. Если в бухгалтерию документы с такой задержкой приходят – это проблемы бухгалтерии, что она не может организовать нормальный доку-ментооборот с организациями-контрагентами по-ставщиков. Это все равно лаг, и лаг бухгалтерии, а не лаг ввода документов. Но это все равно лаг и его надо оценивать. Лаг оценили, галочку поставили на всех объектах учета, где он превышает допусти-мые параметры. В компаниях, в штате которых я раньше работал, сроком предоставления управ-ленческой отчетности был второй день месяца. Со-ответственно, допустимый лаг по вводу докумен-тов – два дня максимум. Сейчас, когда я прихожу в компанию и вижу лаг в три-четыре недели – мне внутренне становится смешно. Я понимаю, каких параметров можно достигать, понимаю, каким образом этих параметров можно достигать и это организовываю. Владельцы бизнеса, как правило, бывают очень довольны.

• Оценить временные затраты на ведение доку-ментооборота в 2-х вариантах.

— Первый вариант – это предоставление экс-пертной оценки от лиц компании о том, сколько конкретно на каждый вид документа в секундах тратится времени.

— Второй вариант – моя экспертная оценка. Раз-ница в экспертной оценке – это тоже серьез-ный показатель. Иногда она достигает 20-30 раз. Когда у меня норматив на ввод документа – 1 минута, а у представителей компании – 30 минут, я понимаю, что на данном блоке учета надо еще поставить третью галочку. Соответ-ственно, здесь у меня будут максимальные ри-ски. Потому что, если пользователи достаточно ленивы, их придется подталкивать, «бить ду-бинкой» и применять другие способы воздей-ствия (также эмоциональный способ).

• Проанализировать документооборот в разрезе пользователей системы. Обязательно. Причем, анализируем уже не в документообороте, а в чи-стом времени. В двух оценках снова – экспертная моя и экспертная представителя компании. Смо-трим недогруз пользователей и перегруз пользо-вателей. Оба блока критичны. Почему? Недогруз – следствие этого лень и халатность пользовате-лей. Встречали, я думаю. Каждый. Перегруз поль-зователей – тоже критичный момент. Почему? Как правило, такие люди выматываются на работе и допускают ошибки по невниманию. И все это по-том разгребать мне.

• Проанализировать документооборот в разрезе организаций. Для чего? Зачастую, когда прихо-дишь в компанию, там структура ведения докумен-тооборота организована не по функциональному признаку, а по юрлицам. Три главных бухгалтера ведут каждый по 40-50 документов в день. Всех устраивает. Общий документооборот – 150 доку-ментов в день. Для меня это – очень мало. На по-стоянной работе, где я работал раньше, нормаль-ная нагрузка была – от 400 до 500 документов на оператора в день. Для меня бухгалтер – это точно такой же оператор. В плане ввода информации раз-личий в моем восприятии нет никакой. Соответ-ственно, недогруз по конкретной организации (юридическому лицу) тоже смотрим обязательно. Есть проблема недогруза – ставим себе на заметку. Плюс – еще следующий момент. Если они разде-лены по юридическим лицам, каждый пользова-тель создает документы по всем объектам учета. Очень много переключений внимания. Соответ-ственно, замедление ввода документов, ошибки в результате переключения внимания и прочее. Соответственно, бонусная задача – добиться ре-структуризации компании на функциональную систему обработки документов – не по юрлицам. Но это уже по воле владельца бизнеса.

• Проанализировать данные по регистрам учета• Проанализировать сходимость отчетных дан-

ных с информационной системой. Как только я появляюсь, мое первое требование:«Предоставьте мне всю сданную фискальную отчетность за по-следние три года. Дальше – предоставьте мне всю отчетность по тому моменту, по которому можете

– 149 –

Алексей Патюков Организация жесткого контроля при внедрении информационных систем

предоставить, которую сдавали владельцам биз-неса и директорату». Сравниваем. Видим расхож-дения, ставим на карандаш. Это – основной блок. Как правило, он занимает от одного дня до двух недель в зависимости от размеров организации. Если в компании бардак, как правило, главные бух-галтера не анализируют документы. Если я вижу неправильно сведенный баланс, если я вижу на 19 счете отрицательные остатки – это качество рабо-ты главного бухгалтера. Таких главных бухгалте-ров надо увольнять. У меня есть такие полномо-чия. Сейчас я расскажу, как я их получаю.

• Собрать информацию о дополнительных затра-тах специалистов. Я это делаю не всегда. Почему? Бухгалтеры утверждают, что они очень много вре-мени проводят за Консультантом, чтением мето-дической литературы и пр. По факту, информацию об изменениях в законодательстве в 75% случаев они получают от специалистов 1С. А вы своих бух-галтеров бухгалтерскому учету не учите? Ну да, ну да… Соответственно, у них есть еще подготовка отчетности. Если учет выстроен, если ежедневно сверяются данные,то сдать отчетность – это дело одного дня. Не надо аврально работать, требовать премии за это. Иначе получается, что бухгалте-ра работают как студенты: «От сессии до сессии живут студенты весело…» Ни одной нормальной компании студенты не нужны. С контрагентами должны работать менеджеры по продажам, либо менеджеры по закупкам, либо специалисты по хо-зяйственной части – в зависимости от входящего или исходящего документооборота. В нормально отстроенной организационной системе бухгал-теры с контрагентами не работают. Моя задача – выстроить структуру документооборота так, чтобы владелец сказал, что «Ты знаешь, меня вот это устраивает больше, чем было раньше».

Работа с владельцами и с дирекцией компании

Продолжительность этой работы может занимать от одного месяца до трех лет. У меня были компании, в ко-торых на время диагностики брался тайм-аут на 3 года.

Расскажу причину. Организация сама работает «на всех парах». Производство загружено полностью. День-ги дает капитально, постоянно. Состояние бухгалтер-ской отчетности владельца не интересует. Все вопросы с налоговой решаются административным путем (есть всякие варианты решения, и если эти варианты рабо-тают, то смысл заморачиваться с бухгалтерским уче-том). Плюс – он получает данные об успешности сво-ей компании не из компании самой, а из внешних источников. Допустим, строительство – это саморе-гулируемые организации. Объем всех строек известен полностью. Соответственно, посчитать свою долю на рынке, ее увеличение или уменьшение – не проблема: две цифры сравнить. И вот тут начинаются проблемы, потому что если владелец бизнеса не заинтересован в

нормальной организации учета, то дальше у меня бу-дет провал где-то в 75%. Я это точно знаю. Моя зада-ча – сместить акцент получения информации о де-ятельности своей компании с внешних источников на информационную базу.

Очень много приходится разговаривать с владель-цами бизнеса. Почему? Разный уровень образования, разные причины создания бизнеса, разный уровень от-ветственности и прочее. Плюс – свои психологические причины. Люблю работать с военными – максимально конкретные люди.

Период смещения внимания с внешних источни-ков на внутренние занял у меня на одном проекте три года. Мы три года с директором общались. Я приходил к нему. Мы пили кофе, разговаривали о цветочках, об-лаках и т.д. Параллельно я его загружал информацией о том, какие виды отчетности бывают, для чего это требуется, какие показатели можно снимать. Три года он мне отвечал так: «Да, все классно, интересно, но… ты же меня понимаешь, Алексей?» «Да, я тебя по-нимаю. Дальше что будешь делать?» «Ну, пока вот так. У меня все хорошо». В этом варианте директор и вла-делец – это одно лицо было. А тут, буквально неделю назад у меня был разговор с ним и он мне: «Алексей, я через два года хочу создавать еще один бизнес. И туда хочу поставить наемного директора. Мне требуется полная прозрачность информации и контроль». Для меня это сразу сигнал – клиент мой. Дальше все стано-вится очень просто, технологично и спокойно.

Обсуждаем временные затраты работы пользо-вателей. Конкретно с владельцем. Все остальное он будет сам делать и достаточно успешно. То есть, если я договорился об акценте на систему–90% моей работы, как технолога, уже сделано. Дальше пойдут просто этапы – шаги, которые достаточно просто ре-ализуются:

• Обсуждение временных затрат сотрудников на ведение учета. Принятие решения о вводе нормирования работ сотрудников. Человек сам принимает решение, какой экспертной оценке верить. Либо верить своему главному бухгалтеру, либо верить мне. По необходимости я могу само-стоятельно, в качестве оператора отработать весь блок учета. Если надо вбить 1000 документов в те-чение двух дней – пожалуйста, спокойно сажусь и

– 150 –


вбиваю. Человек видит, что норматив достижим и, соответственно, свое решение принимает.

• Обсуждение слияния, разделения функций уче-та по сотрудникам. Это я о том, что в случае, если среди сотрудников идет разделение обязанностей по ведению документооборота по юридическим лицам, то желательно перенести это разделение обязанностей на функциональные блоки учета. Но владелец сам принимает решение, как это будет выглядеть. Почему? Это его бизнес. Я не вправе ломать постройку его бизнеса. Он сам его отстра-ивает. Он знает те принципы, на которых он свой бизнес строил. Иногда бывают некоторые вещи административные, которые он не хочет менять в соответствии с работающими сотрудниками. Но, конкретно, когда мы обсудили эти функции, мы видим новую структуру нормирования времени.

• Обсуждение кадровых перестановок, увольне-ния и найма персонала. Принятие решения об изменении штатного расписания. У 90% случаев проблемных клиентов вопрос звучит так: «Главно-го бухгалтера увольнять будем?» Просто стандар-тно. Допустим, в 2009 году у моих клиентов было четыре главных бухгалтера уволено. Это простой вопрос. Это вопрос технологичный. Если вы хоти-те успешно завершить проект, и потом ни с кем не судиться, а просто нормально пожать друг другу руки, здесь выход. Тотальная смена персонала по проблемным участкам. Сразу говорю, там, где есть финансовый директор, вопрос о ценности главного бухгалтера не стоит в принципе. Главные бухгалтеры в данных компаниях – расходный ма-териал. Меняются просто щелчком пальцев. Мне тут говорят, что финансовый директор отвечает за финансовую часть, а главные бухгалтеры отве-чают за регламентированный учет. Все согласны? Нет. В большинстве случаев это не так.

• Обсуждение ФОТ сотрудников на ведение учета. Принятие решения об изменении ФОТ. Возвра-щаю директора к первому своему пункту «Собрать сведения об общем отражаемом документооборо-те» и напротив каждого документа я показываю стоимость введения этого документа в рублях. По-казываю ему калькулятор аудиторских бухгалтер-ских фирм, где есть норматив на введение этого же документа (сейчас очень много контор пользуют-ся калькуляторами, чтобы привлекать себе биз-нес). Так вот. У меня было забавное расхождение. Стоимость ведения учета с точки зрения ауди-торов – 100 рублей за документ. По факту затрат только на ФОТ, без учета налогов, взносов и всего остального, на данном предприятии было 543 ру-бля 74 копейки. Представляете – вбили один доку-мент – все, 540 рублей вам зарплаты капнуло. Зна-ете, я хочу работать на такой работе. 500 рублей за транзакцию, практически.

• Определение порядка внедрения блоков ИС. Назначение ответственных лиц. Завершающая

фаза – на владельце. Говорю еще раз, у меня вла-дельцы бизнеса – это те, кто этот бизнес отстра-ивал сам. Поэтому этот момент мы отрабатываем с ними. Владелец сам скажет, какие блоки ему важны. Ему без разницы мнение пользователей (бухгалтеров, менеджеров отдела продаж). Он показывает те блоки, которые важны ему здесь и сейчас. Потому что бывают различные ситуа-ционные вещи, которые пользователь просто не сможет рассказать. Владелец имеет информацию внутри организации и внешнюю.

Ремарка: Основные задачи фрилансера• Первое – получить с клиента деньги, потому что

нужно все-таки кормить семью;• Второе – запустить «сарафанное радио» с помо-

щью клиента. • Если я получаю «сарафанное радио» от владельца

бизнеса, то от бухгалтера оно мне не нужно. Бух-галтер и владелец владеют разными финансовы-ми потоками. Бухгалтеры оперируют суммами в 10-20 тысяч рублей на расходы, а владелец при-нимает решения в принципе.

За фазу запуска нельзя удовлетворить всех. Я спокойно работаю в агрессивной среде, я заранее на это настроен, но те действия, которые я выполняю, нравятся владельцам бизнеса.

Работа с сотрудниками

Самое главное – это назначение ответственных лиц. Как правило, здесь мы начинаем привлекать со-трудников компании и начальников подразделений.

Как это бывает? Когда я ввожу экспертную оценку, владелец бизнеса говорит: «Ты молодец, ты хорошо все говоришь. Давай посмотрим, что скажут мои со-трудники». Как правило, приглашаются начальники подразделений, либо экспертные сотрудники в этом подразделении. Или, зачастую, сначала приглашается начальник, а потом эксперт.

Так вот, уже здесь я уже могу прогнозировать с ве-роятностью 75% еще дополнительные риски по пер-соналу на внедрение проекта.

Пример простейший, буквально в прошлую сре-ду: общение в кабинете владельца, приглашены на-чальник производства и начальник отдела продаж. Не приходит ни начальник отдела производства, ни начальник отдела продаж. Приходит их подчиненная, которая начинает вываливать свои мелкие проблемы владельцу бизнеса. Так вот, для себя я сразу ставлю та-кой момент, что руководителям подразделений дан-ный проект неинтересен. У них все хорошо, бонусы, все замечательно, все прекрасно. Еще одна галочка – я понимаю, что мне, возможно, придется бить руководи-телей подразделений.

Моя самая главная задача – взять для себя на за-метку, где у меня будут провалы, и это обсудить с вла-

– 151 –

Алексей Патюков Организация жесткого контроля при внедрении информационных систем

дельцем. Самое интересное, что вот здесь владелец начинает крутиться очень сильно. Он сам берет свою биту и идет наводить порядок. Потому что, как толь-ко он понимает, что части сотрудников его бизнес не-интересен, для него это показатель их производитель-ности труда, причем, никак не отраженный.

Итак, работа с сотрудниками. • Когда у нас уже все определено, нам надо опове-

стить о предстоящих изменениях всех сотруд-ников. Так называемое PR-мероприятие – обя-зательный процесс. Причем время начала – это половина времени проекта по внедрению. Если проект по внедрению – год, то PR – за полгода. Ина-че вы не сможете некоторые ключевые моменты донести до пользователей, когда компания, допу-стим, территориально распределена

• Выделение рабочей группы. Как правило, уже на встрече с собственниками понятно, кто будет ра-бочей группой. Либо это будут руководители под-разделений, либо ключевые сотрудники организа-ции – в зависимости от поведения сотрудников и руководителей на совещаниях в кабинете владель-ца. И с этого момента мы говорим, что эта группа, которая у нас проявила ответственность, ини-циативу, внесла рациональные предложения, – занимается внедрением системы.

• Нейтрализация «неприкасаемых». Ситуация какая: некоторых сотрудников нельзя уволить. В принципе. Есть, допустим, политические моменты, в которых они работают. На заводе (мясокомбина-те) работал сын одного из «генералов», приятеля владельца бизнеса. То есть, сына этого надо было куда-то устроить. Его устроили начальником от-дела администрирования системы. Квалификация ноль. Пинать его мне запретили: «У него там папа, а папа мне нужен, нужен очень сильно». Что дела-ем? В данном случае говорим: «Денис, поздравля-ем, у тебя повышение» и берем ему в подчинение сотрудника. Директор понимает, что это его ор-ганизационные расходы на ведение бизнеса, которые позволяют ему бизнес вести и фиксиру-ет ему зарплату: «Раз сын генерала, значит, минус 50 тысяч из бюджета ежемесячно». Он просто эту цифру зафиксировал и все. То есть, либо взятку давать, либо сына держать на работе. Взятку больше. Сына меньше.

Запуск

Если кратко:• Ввод наблюдателей – конкретно людей «с би-

тами», которые посекундно контролируют ввод документации на проблемных участках. Причем при полной замене неугодного персонала наблю-дателей можно будет убрать, они будут не нужны. Как правило, наблюдателями являются просто консультанты компании-внедренца, которых я туда привлекаю дополнительно за определенные деньги. Владелец бизнеса с этими расходами согла-шается, понимает, что они нужны.

• Ввод администратора информационной систе-мы. Примерно в 80% проблемных предприятий такого понятия, как «администратор информа-ционной системы» даже нет. Есть программист, который решает проблемы, а вот понятия «ад-министратор информационной системы» нет. Но администратору можно платить 30 тысяч рублей, а программисту – 70. Администратором может быть достаточно опытный пользователь. Изна-чально я им предоставляю своего администрато-ра системы, а потом эту функцию мы переводим в функционал предприятия. Его задача – контроли-ровать работу системы и снижать количество ошибок.

• Контроль поступления первичной документа-ции. Мы должны зафиксировать все информаци-онные потоки и поставить их на карандаш.

• Обучение с вводом нормативов. Я требую, чтобы у пользователей была буквально физиологиче-ская память. То есть, если документ вводится, то он вводится со строгим порядком, ни шага влево/вправо на обдумывание, на принятие каких-то ре-шений. Моторика достигается за 50-100 повторе-ний ввода одного документа. Под секундомер, под мою монотонную речь, с указаниями реквизитов, которые необходимо заполнить в порядке их за-полнения и прочего.

• План по вводу первичной документации. Каж-дый день каждый пользователь обязан вводить какую-то норму документов. Поток должен быть постоянным. Если бухгалтерия предпочитает в конце месяца разносить документы, здесь у меня такая фишка не прокатит. Я знаю период форми-

– 152 –


рования документов от каждого контрагента-по-ставщика организации, период счетов-фактур, период прихода товаров, порядок выставления документов от транспортных организаций и пр. Я знаю, как часто они должны попадать в систему. Я это контролирую.

• План-фактный анализ ввода первичной доку-ментации. Как только я вижу расхождения где-то, я иду в это подразделение сам. Сначала я разгова-риваю об этом со своим наблюдателем. Почему так произошло? Ребята, что вы здесь делаете?

• Контроль регистров учета. Здесь понятно.• Экзамен-тестирование. По-другому – публичная

порка. Через две-три недели, после старта (запуска системы) публичное тестирование с представи-телями владельца, либо с этим владельцем. Кон-кретно: человек обрисовывает свой докумен-тооборот, объясняет, почему таким образом это все заводится и т.д. Здесь есть плюсы – в одной конторе мне удалось на варианте экзамена-тести-рования уволить несколько главных бухгалтеров. Потому что я прошу: «Ребята, покажите мне, пожа-луйста, как вы начисляете зарплату, проанализи-

руйте, что у вас получилось и все остальное». Ни бе, ни ме. Почему? Люди вводят зарплату один раз в месяц. Каждый раз они начинают судорожно ли-стать свои учебники с вопросом: «А как же зарпла-та вводится?» Когда у меня таких было 18 юрлиц, мы что сделали? В одном юридическом лице было 100 сотрудников и выделенный специалист по ЗУП, который начислял зарплату, а у остальных это делали главные бухгалтеры. Директор сам видит скорость ввода документа по каждому сотруднику и говорит – «Слушай, а у меня зарплату по всем юр-лицам может и один человек начислять».

• Ввод временных исполнителей. Необходим при жестком саботаже определенного дела. Просто я нанимаю с рынка бухгалтеров, которые проходят это тестирование за двойной оклад, потому что это временная проектная работа. Люди с удоволь-ствием идут, временно со мной работают, проект закрывается, они идут дальше. Некоторые потом говорят: «Алексей, проект будет – звони. С тобой в два раза интереснее».

При такой ситуации судиться с владельцем бизнеса в принципе нет необходимости.

– 153 –

IT due diligence: как ИТ-служба может повысить стоимость компании

Франц БдоянМенеджер отдела анализа и контроля рисков PwC в Санкт-Петербурге

Представлюсь. Меня зовут Франц. Я руковожу прак-тикой анализа и контроля рисков в PwC в Санкт-Пе-тербурге, в регионах. Я также являюсь руководителем института внутренних аудиторов по Северо-Западу. По совместительству работаю еще независимым членом совета директоров одной производственной химиче-ской компании.

Обычно, когда в пятницу, в 17:30 проходят такие конференции, я слушаю презентации в положении «на низком старте», готовый скорее сорваться домой на выходные. Думаю, вы тоже сейчас слушаете меня в таком же положении. Но, на самом деле – тема очень интересная.

Почему? Давайте на минутку закроем глаза и пред-ставим себе, что мы хотим купить замок в Англии, где-нибудь под Манчестером. И нам надо выяснить, правда или нет то, что написано в буклете – что там есть всякие DVD-системы, 50 телевизоров, бесперебой-ное электропитание и так далее. Чтобы это выяснить, я могу отправить туда своих детей, которые, скорее всего, пришлют мне отчет о том, что там не хватает Xbox-ов, SonyPlayStation, на компьютерах не установ-лен Warcraft и нет iPad-ов на холодильниках.

И инвесторы, и компании, которые собираются покупать какие-то (любые) активы, они понимают, что их ИТ-служба выдаст примерно такие же хотелки, и поэтому для анализа инвестиций в области ИТ они приглашают внешних независимых экспертов-кон-сультантов.

В связи с этим становится понятно, что такое ITDueDiligence – это комплексный анализ инфор-мационных технологий для того, чтобы выявить риски, связанные с покупкой каких-либо активов.

Зачем нужен этот IT Due Diligence? Если вы не против, я также буду называть его ИТ-а-

нализом.

Для того чтобы ответить вам на этот вопрос, я со-брал несколько фактов из зарубежной практики, по-казывающих, насколько велики риски в области ИТ.

• Ну, например, исследование Symantec, которое рас-сказывает о том, что:

— все компании сталкивались с хакерскими атаками

— И 98% из них испытывали от этого какие-то материальные потери

— А 46% из-за этого имели существенные про-стои в работе.

• Другая компания исследовала, что: — 50% компаний, которые испытывали дей-

ствие чрезвычайной ситуации и теряли дан-ные на этом – в течение двух лет просто за-крывались

— А данные другого исследования американско-го бюро статистики указывает, что в течение пяти лет после подобных чрезвычайных ситу-аций, связанных с потерей данных, закрыва-ются почти все подобные компании – 93%.

• Другой пример из малого бизнеса: малый бизнес терпит потери ввиду того, что они используют нелицензионное программное обеспечение. Им приходится платить за использование нелицензи-онного программного обеспечения до двух мил-лионов фунтов стерлингов в год в виде штрафов

– 154 –


и других платежей. У нас эта цифра может быть больше или меньше, чем в Англии, но от этого нам лучше не становится.

• HSBC была оштрафована на 5 миллионов дол-ларов за то, что они не имели контрольных про-цедур по части информационной безопасности (у них были утеряны два незашифрованных дис-ка с персональными данными клиентов).

• Примеров – масса. Сегодня было очень много об-суждений на тему проектов. И в проектной де-ятельности таких примеров тоже очень много. Например, в английской национальной службе расследований при внедрении информацион-ной системы бюджет проекта был превышен в два раза, а внедрение закончилось на три года позже запланированного.

Хорошо. Примеров очень много и всесторонний ИТ-анализ может помочь вовремя обратить внима-ние на эти риски с целью их минимизации.

Может ли комплексный анализ ИТ затронуть и нас?

Это, на самом деле, цифры, которые я увидел в на-шей российской практике.

• В 2010 году из тех компаний, который проходили в целом финансовый DueDiligence, только 5% про-ходили еще и ITDueDiligence

• В 2011 году эта цифра увеличилась до 7%• В 2012 году уже 15% проектов включали в себя

ИТ-анализ.

Что происходит в Великобритании, где это уже по-ставлено на конвейер?

• в 2012 году в 80% случаев при покупке какой-то компании обязательно проводится ИТ-анализ.

И, чтобы еще больше тема была актуальна – я могу сказать, что уже сейчас в России, в подавляющем боль-шинстве случаев (98%), аудит финансовой отчетно-сти включает в себя некий ИТ-анализ. Сокращенную его версию. То есть, если в вашей компании такой ана-лиз не проводился, то, скорее всего, через три-четыре года, практически 100%, вы увидите запрос аудитора на предоставление информации. Большинство ваших сотрудников будут проходить интервью с аудитором, который затем напишет какой-то отчет.

Поэтому эта тема, на самом деле, очень актуальна. Она смотрит немножко вперед, но уже сейчас видны в этом деле какие-то подвижки.

Что такое ИТ-анализ? Что он в себя включает?

• В первую очередь, аудитор обычно хочет понять, как устроена ИТ-среда

• Он хочет выяснить и оценить риски, связанные со сделкой

• Он хочет понять, какие будут возможны угрозы по части ИТ при будущей интеграции двух ком-паний – той компании, которая покупает и той компании, которая покупается

• Ну и, нужно оценить эти риски каким-либо обра-зом, чтобы их можно было представить в измеря-емом цифрами виде.

Четыре опорные линии комплексного анализа ИТ

Смотрите, на самом деле этот анализ держится на четырех столбах. Тут все написано.

• Направление ИТ-анализа «Увязка со стратегией и деятельностью компании» (первая колонка).

— Пример: Помните, совсем недавно несколько банков, и российских, и иностранных – закры-вали свои филиалы и представительства по работе с физическими лицами. Так вот, экс-перты утверждают, что одной из причин, по-

– 155 –

Франц Бдоян IT due diligence: как ИТ-служба может повысить стоимость компании

чему это было сделано, явилось то, что ИТ не успевало за стратегией компании.

• Другая область, которая закрывается ИТ-анализом – это «Организация и квалификация сотрудни-ков»

— Пример: Около двух недель назад я встречался с одним финансовым директором аграрно-про-мышленной компании, и он мне говорит – «У нас 28 баз 1С, которые администрировались, поддерживались и все изменения, которые были внедрены, – делались одним человеком и этот человек сейчас уволился. Мне нужен кто-то, кто во всем этом разберется». Причем, он приглашал двух отдельных людей, которые просто не разобрались в этом коде и уволились через месяц. Выявление ключевых сотруд-ников – это одна из основных целей ИТ-ана-лиза. И, как я вижу по этому залу, порядка 500 компаний в эти два дня сталкиваются с теми же проблемами, поскольку их ключевые сотрудни-ки, собственно, находятся здесь.

• По примерам из «Технологии и архитектуры» и «Руководству и корпоративному управлению» – недавно, во время совета директоров, директор по ИТ нашей компании рассказал мне историю о том, что, когда он работал на предыдущем месте работы, там проводили IPO-диагностику. Это де-лается, оказывается, в течение двух дней, как он сказал. Там пришли и всего за два дня выяснили, что в компании недоинвестируют в ИТ, ввиду этого есть проблемы с информационной безо-пасностью, с контролями, и пр. И, ввиду этого, им просто пришлось отложить IPO.

Я думаю, что это очень полезно знать и приводить руководству и владельцам бизнеса, поскольку эти примеры позволяют людям быть спокойными относи-тельно того, сколько денег они внедряют в ИТ.

Примеры выявленных рисков по итогам ИТ-анализа

в различных российских компаниях

Еще несколько примеров, которые я взял – специ-ально каждый пример приведен в кавычках, потому что я даже не изменял текст. Здесь приведены приме-ры выявленных рисков по итогам ИТ-анализа в россий-ских компаниях.

Давайте пройдемся по нескольким самым интерес-ным.

• Например, у нас есть закон о защите персональ-ных данных (152-ФЗ). В нем освещено очень мно-го рисков, контроль над которыми очень важен для иностранных инвесторов. Если кто-то стал-кивается с ними, то очень важно об этом помнить

• Потенциальные убытки, связанные с отсутстви-ем необходимого количества лицензий – понят-но

• То, что в ИТ-бюджете не предусмотрен достаточ-ный объем средств для замены ключевого обо-рудования, – понятно

• В компании отсутствует формализованная про-цедура оценки ИТ рисков – понятно, что сейчас, может быть, этого нет, но это будет становиться из года в год все актуальнее

• Что может быть более интересным для нас сейчас – это, например, «Прямой доступ разработчиков в продуктивную среду использующихся систем». Казалось бы, что здесь такого? Мы же разработчи-ки! Мы вообще аутсорс-провайдеры и мы отвечаем за работоспособность системы. Почему бы нам не дать прямой доступ к этой системе, чтобы с ней ра-ботать. Как оказывается – внешний аудитор это будет отмечать как существенный недостаток

• Также еще один факт – «Результаты тестирования изменений, вносимых в информационную систему, не всегда фиксируются, а, следовательно, не могут

– 156 –


быть проконтролированы». Понятно, что тестиро-вание всех изменений обязательно нужно доку-ментировать

• «Отсутствие разделения сред: разработки, те-стирования и продуктивной среды». Казалось бы, вроде обычная вещь, но – внешний аудитор отмечает это как существенный недостаток

• Также неограниченный доступ к локальным конфигурационным файлам баз данных у биз-нес-пользователей

• и различные недостатки в области разграниче-ний прав и полномочий.

История №1 о роли ИТ-анализа при совершении сделок

Хочу еще рассказать несколько историй.

Первая история о том, как одна компания пыта-лась купить другую, и в стоимость сделки не были включены некоторые капитальные затраты на ИТ. И, чтобы помочь нашему клиенту снизить стоимость покупки, мы провели такой анализ и мотивировали те капитальные вложения, которые предстоит сде-лать.

История №2 о роли ИТ-анализа при совершении сделок

Другой пример – из области финансовых институ-тов. Один из крупнейших российских банков пытался приобрести компанию, занимающуюся производством

программного обеспечения, и им требовалось для этой компании определить размер возможных затрат на ИТ (в частности, интересовал размер затрат, требуе-мых для завершения текущих ИТ-проектов), чтобы учесть стоимость этих затрат в сделке. Ну и ИТ-ана-лиз помог выявить все эти проблемы.

Примеры наших рекомендаций в среде контроля ИТ

Теперь немного о том, какие рекомендации мы даем нашим клиентам, чтобы они, если придет ка-кой-то внешний аудитор или оценщик, соответство-вали требованиям или, как минимум, чтобы из-за со-стояния компании в области ИТ стоимость сделки не изменилась, что очень важно.

Опять же, все эти рекомендации представлены в кавычках, потому что они «вырваны» из отчетов.

• «Мы рекомендуем разработать и утвердить по-литики, стандарты и процедуры, которые бы обеспечивали эффективное управление ИТ». Наверняка, у вас есть положение об отделе. Здесь все немножко шире.

• «Разработать и утвердить Стратегию развития ИТ». Стратегия развития ИТ обязательно должна присутствовать.

• «Разработать и внедрить процесс выявления и оценки ИТ-рисков». Здесь, если у вас в компании нет отдела управления рисками или людей, отве-чающих за это, то одному все это сделать очень тяжело. Поэтому здесь вы можете быть инициа-тором того, чтобы в ваших компаниях появилась формализованная оценка рисков. В том числе, ИТ-рисков.

• «Определить ключевые информационные ре-сурсы и назначить владельцев этих ресурсов». Когда я с финансовым директором агро-промыш-ленного комплекса говорил про эти 28 баз, я его спросил – «А кто отвечает за эти базы? Кто владе-лец этого информационного ресурса?» И никакого ответа не последовало, потому что этого просто сделано не было. А владельцы у ключевых инфор-мационных ресурсов должны быть.

– 157 –

Франц Бдоян IT due diligence: как ИТ-служба может повысить стоимость компании

• «Проводить регулярный мониторинг соответ-ствия регламентирующих документов измене-ниям в организационной структуре компании, а также ее целям». Это немного связано с первым пунктом.

• «Внедрить процедуру регулярного внутреннего аудита информационных технологий». Опять же – прежде чем кто-то тебя придет проверять снару-жи, лучше всего это сначала сделать внутри ком-пании. Очень многие мои коллеги из консалтин-га уходят в бизнес и занимаются аудитом внутри компании, и это дает свои плоды.

Примеры наших рекомендаций в сфере эксплуатации компьютерных систем

В сфере эксплуатации компьютерных систем – у нас есть некоторые замечания, среди которых я выделил самые часто упоминаемые

• «Рекомендуем разработать детальный план по обеспечению непрерывности бизнеса Компа-нии» – так называемый businesscontinuityplan

• «Разработать план действий в части ИТ при воз-никновении ЧП» – это disasterrecoveryplan

• «Разработать и ввести в действие Регламент по выполнению резервного копирования» – навер-няка он у всех есть

• «Уровень физической защиты серверных поме-щений должен соответствовать требованиям ограничения физического доступа».

• «Обеспечить использование только официаль-ной и лицензионной программной продукции в рабочей среде на предприятии»

Примеры наших рекомендаций касательно разработки и изменения

программного обеспечения

Что в части внедрения и изменения существующих программных продуктов мы обычно рекомендуем?

• Мы рекомендуем полностью разграничить сре-ды разработки, тестирования и эксплуатации

• Мы рекомендуем разработать инструкцию, регу-лирующую процесс переноса изменений в рабо-чую среду

• Мы рекомендуем разделить функции по разра-ботке программного обеспечения и переносу изменений в рабочую среду

• И самое интересное здесь – это разграничение прав и полномочий в информационной систе-ме, что часто упускается ввиду того, что нам не хватает времени или ресурсов или это просто не считается важным.

Примеры наших рекомендаций касательно информационной безопасности

и разграничения доступа

По информационной безопасности здесь представ-лено очень много деталей, но я бы сказал так: вопрос информационной безопасности сейчас становится очень актуальным.


На самом деле, ITDueDiligence – это такой модный термин, но я хотел бы, чтобы каждый из нас задумался и провел некоторый DueDiligence в своей сфере, в которой он работает. И, надеюсь, все эти пункты вам помогут.

– 158 –

Я аттестованный специалист, или Без бумажки ты букашка!

Павел ЧистовМетодист по платформе 1С:Предприятие 8, сертифицированный преподаватель ЦСО. chistov.pro

От ведущего: Я вам сейчас расскажу историю из своей жизни. В 2003 году я сдавал экзамен на сертифи-кат. Но я же максималист, и я тогда решил, что мне нуж-ны все сертификаты из линейки 1С. И поэтому тогда я сразу начал готовиться на весь спектр – и, в конце кон-цов, вообще ушел в другие платформы. И, самое инте-ресное, что, когда мне уже надо было сдавать экзамен, я почему-то вдруг понял, что мне сертификаты уже не нужны. Так что у меня сейчас нет ни одного сертифи-ката. Правда, я сейчас жалею о том, что тогда пошел таким путем. Если бы я осваивал все по порядку, мне бы чуть легче было. То есть, это моя ошибка. Мне инте-ресно мнение Павла об этой ситуации. Павел, как ты к этому относишься?

От докладчика: Я как раз и собираюсь рассказать, как к этому отношусь я и почему у тебя возникло ощу-щение, что тебе этот сертификат не нужен.

Меня зовут Павел Чистов. Я методист по платфор-ме. Я преподаватель.

О чем мой доклад? Я хочу рассказать про сертифи-каты, о том, зачем они нужны, и почему не нужны сер-тификаты от 1С (как это ни странно).

Почему возникла тема такого доклада?

Здесь перечислены все причины того, почему сер-тификаты мне не нужны. То, о чем мы с Алексеем толь-ко что говорили.

• Я и так знаю, зачем мне эта бумага. Ну, будет она висеть. Но я ведь время потрачу на подготовку. Там нужно же задачи какие-то прорешать, еще что-то, а у меня работы выше крыши. Ну скажите, кто не получил сертификат только потому, что просто нет времени – горит проект. Ведь есть же такие?

• Или же, например, мне говорят – «К нам пришел человек устраиваться на работу с бумажкой. А он ничего не знает». Из этого следует, что сертифи-кат этот ничего не значит, и человек этот серти-фикат купил.

Это основные причины того, отчего так наболела тема этого доклада.

Виды аттестаций 1С

Для начала я расскажу вам о том, какие сертифи-каты у 1С есть, что подразумевает сама фирма 1С под этими сертификатами, а также, почему они у них поя-вились.

Здесь снизу вверх представлены виды аттестаций фирмы 1С. Три ступени:

• 1С:Учебное тестирование (соискатель)• 1С:Профессионал (профессиональный пользова-

тель)• 1С:Специалист (квалифицированный специалист

– программист, консультант)

Про учебное тестирование говорить ничего не буду. Вообще не интересно. На сайт можете зайти, по-смотреть. Это для школьников, наверное. Подготовка к профессионалу.

1С:Профессионал

А вот про 1С:Профессионал хотелось бы отметить.

– 159 –

Павел Чистов Я аттестованный специалист, или Без бумажки ты букашка!

Есть такой сертификат 1С:Профессионал. Все его, наверное, знают и пробовали его сдавать. Раньше на дисках ИТС они публиковались. Вот у меня есть очень любимый вопрос из 7.7. Я его не дословно привел, но он где-то так и выглядит:

«Какого цвета галочка на значке проведенного до-кумента, находящегося позже точки актуальности?»

Вот эти галочки здесь изображены. Какого они цве-та? Понятно, что не красный. Но такого и не было вари-анта ответа. Были варианты ответа:

• Черный • Серый• Синий

Мы замеряли в Paint специально с коллегами – не подходит ни один. Что проверяет этот вопрос? Угадай-ка какая-то.

Я, конечно, согласен, что сертификат 1С:Профес-сионал – это хорошая штука, чтобы закрепить ба-зовые принципы и удостовериться о том, понимает ли человек, на какую кнопку надо нажать, чтобы получить такой-то результат или нет. Но мне прав-да кажется, что это угадайка в прямом смысле сло-ва – повезет/не повезет. Хотя вообще к этому можно по-разному относиться.

Сертификат 1С: Специалист по прикладным решениям

Следующий сертификат – это уже сертификат 1С:Специалист. Сертификаты 1С:Специалист, они, ко-нечно же, нужны. Зачем?

Например, специалист по прикладным решени-ям. 1С считает, что, если человек сдал этот экзамен, то он уже готов внедрять (дорабатывать) целевую типовую конфигурацию. Но вот смотрите – конфи-гурации меняются. Человек получил сертификат по 1С:Бухгалтерии 8.0 какой-то лохматой редакции. А сейчас уже вышла на управляемых формах эта бух-галтерия. И что получается? Он – обладатель сертифи-ката. Вот, он пришел устраиваться на работу. Он этот сертификат работодателю показал, и его посадили к клиенту. А работать-то он не может, потому что все по-другому стало.

Сертификат 1С:Специалист-консультант

Ситуация приблизительно такая же, как и со специ-алистом по прикладным решениям. Да, это хороший консультант, который в совершенстве знает законо-дательство, знает, как это реализовано в 1С. Умеет ли эта конфигурация это делать или не умеет.

Но, опять-таки, законодательство меняется и конфигурация меняется. И опять мы придем все к тому же.

Сертификат 1С:Специалист по платформе

При сдаче экзамена дается билет. Там задание, ко-торое не формализовано конкретно, как ТЗ. Следова-тельно, этот специалист (как тут внизу у меня напи-сано) не будет требовать побуквенного ТЗ. И человек, получивший такой сертификат, позиционируется как готовый разработчик.

Но. Что проверяется? Опять же, у человека есть сертификат 1С:Специалист по платформе, получен-

– 160 –


ный, например, по версии 8.0. Версия 8.0 – это обычное, не управляемое приложение. Сейчас сдают сертифика-ты 1С:Специалист по версии 8.2. Там появилось управ-ляемое приложение. А этот человек, например, с ним работать не умеет.

Для сдачи экзамена 1С:Специалист по платформе проверяется конкретное умение работать с:

• Регистрами накопления• Регистрами сведений• Регистрами бухгалтерии• Планами видов характеристик• Запросами• Еще и формы там недавно добавились.

Как вы понимаете, в платформе же механизмов больше.

К чему это приводит? Человек с сертификатами 1С:Специалист приходит в организацию устраиваться на работу и говорит: «Вот я – Специалист!» Ему гово-рят – «Ну иди настрой там обмен данными между дву-мя этими базами». Оп-па! А как?

Из всего этого следует, что сертификаты 1С:Специ-алист имеют недостатки:

• они, во-первых, как мне кажется, устаревают, • а во-вторых, они полностью не охватывают все

потребности, которые должны быть оценены ка-ким-либо образом.

Сертификат 1С: Эксперт по технологическим вопросам.

Вот, на мой взгляд, это единственный сертификат, который не утратил своей компетенции. То есть, до-верие к этому статусу сейчас довольно высокое – это мое личное мнение.

Про него ничего говорить не буду. Такой сертифи-кат получать от фирмы 1С нужно, он актуален. Это здорово, я этих людей очень уважаю, честное слово.

Сертификат 1С:Руководитель проектов

Если я правильно помню, экзамен на этот сертифи-кат раз в два года сдают. И в 1С считают, что если в ко-манде есть руководитель проектов с такой бумажкой – все, любой проект будет внедрен.

Конечно, идея была хорошая. Реализация этой идеи тоже хорошая. Но не все руководители проектов чи-тают те методические материалы, которые им нуж-но читать. И сдают этот сертификат, как правило, фор-мально. На качество предоставляемых услуг этот сертификат редко влияет.

Зачем нужны сертификаты?

Теперь давайте разберемся, зачем вообще нужны сертификаты? И нужны ли они вообще? Как вы счита-ете?

Давайте разбираться. Да, нам нужен какой-то кри-терий оценки, правильно? Чтобы как-то оценить че-ловека. Как? Это другой вопрос.

• Зачем сертификаты нужны фирмам-франчай-зи? Фирмы-франчайзи являются партнерами фир-мы 1С, а фирме 1С нужно рейтинг выстраивать, чтобы подстегивать качество предоставляемых услуг в самих этих фирмах франчайзи. Правильно? Правильно.

• Зачем нужны эти сертификаты клиенту? Он обращается в фирму-франчайзи или в какую-то проектную команду. И ему нужно понять – все ли хорошо в проектной команде, потому что он не работал с этими людьми. Поэтому, какой-то крите-рий оценки нужен.

• Работодателю? Приходят два человека. Один с сертификатом, другой без. Кого возьмут? Того, кто умеет работать, совершенно верно. Но если пришло 150 человек и надо быстро принять ре-шение – кого будем проверять? Всех 150 прове-рять не будем. Будем проверять только тех, у кого есть сертификаты, а там уже будем их сортировать. Правильно?

• Ну и, зачем нужен сертификат специалисту? Со-вершенно верно, потешить самолюбие.

– 161 –


Отрицательные стороны сертификации

Вот. Давайте разберем отрицательные стороны сертификации.

Я о них уже немного рассказал. Но, давайте еще раз.• Зазвездившиеся спецы. Когда специалист полу-

чает очередной сертификат, у него чувство соб-ственного достоинства от этого вырастает, и он го-ворит своему работодателю «Хочу больше денег» или, например, раньше он развозил ИТС, а теперь говорит «Да вы чего? У меня сертификат. Я не по-еду». И все. Причем, этот специалист будет пери-одически требовать повышения оплаты – боль-ше, больше и больше. Но, по факту, у него ведь есть только две ступени – нет сертификата, и есть сертификат. А дальше мы уже не можем оценить – развивается он или не развивается.

• Франчайзинговое рабство. Что я под этим под-разумеваю? Человек получает сертификат, рабо-тая во франчайзи. И на протяжении двух лет он не может перевести этот сертификат без согласия франчайзи или оплаты этому франчайзи опреде-ленной суммы денег (1000 условных долларов в первый год или 500 условных долларов во второй год). Причем, довольно интересная ситуация полу-чается в случае, если человек сам, как физлицо, по-лучает сертификат, потому что, когда он приходит работать во франчайзи, его личный сертификат автоматом, без каких-либо дополнительных согла-шений, приписывается этому франчайзи. И все. Он опять же, два года не может без согласия этого франчайзи перевести этот сертификат. Правда, мне говорили, что сейчас это поправилось. Поэто-му я не берусь утверждать на 100%. Но все равно, у нас такие понятия, как личный сертификат и сертификат франчайзи, отсутствуют.

• Несмотря на это, в фирмах текучка постоянная, специалисты переходят из одной конторы в дру-гую. Причем они говорят – «Да можно же и не пе-реводить на другую фирму эти сертификаты, меня туда и так возьмут, потому что я же теперь специа-лист, а там денег предлагают больше».

• А самое плохое, как мне кажется, это – универсаль-ность сертификата. Вот мы получили сертификат по платформе 8.0. Он висит у нас на стене. Там на-писано, что я являюсь мега-супер-специалистом по системе программ 1С:Предприятие 8. Потом вы-

шла 8.1, 8.2, 8.3. А этот человек с этим сертифика-том может сказать, что он умеет писать мобильное приложение на 1С:Предприятие? В общем случае – не может. Поэтому, вот эта бумажка не говорит ничего об уровне его компетенции на текущий момент времени.

Что делать?

Почему так в итоге получилось, мы обсуждать не будем.

• Нам нужна адекватная сертификация с таблицами компетенций. То есть, не просто бумажка, на кото-рой написано, что я вот мега-супер и все. Нам нуж-но конкретно знать, что человек знает и что он не знает. Во-первых.

• И нужна гибкая система владения сертифика-том. Чтобы франчайзингового рабства у нас не было. И здесь есть две вещи, которые очень хоте-лось бы получить:

— Например, человек сам получил сертифи-кат и может им распоряжаться – устроиться на работу. Программистам это выгодно. Они должны хотеть иметь свой собственный, лич-ный сертификат.

— Или, например, у нас организация аттесто-вала своих сотрудников – весь свой отдел, и тогда они, эти сотрудники, не должны иметь возможности хвастаться своим профессиона-лизмом перед другими компаниями ради того, чтобы получить конкурентное преимущество при устройстве на работу, потому что, по сути, не они заказали эту оценку.

При этом я не имею в виду, что только сотрудник получил сертификат и он им владеет или только ком-пания заказала для своих сотрудников сертификацию и только она этими сертификатами владеет. Они могут договориться. Я имею в виду, что должны быть нор-мальные адаптивные механизмы передачи серти-фикатов от одной компании к другой. Чтобы не было такого, что без тысячи долларов мы никак не отдадим и все. Должна быть какая-то гибкость, все-таки. Пускай он отработает три месяца и идет со своим сертифика-том. Может быть, это устроит обе стороны.

– 162 –


Альтернативная сертификация. Преимущества

Я все это веду к тому, что нам нужна некая парал-лельная сертификация, более аккуратная.

Причины:• Независимость от 1С. Я не имею в виду, что неза-

висимость от 1С – это чтобы совсем 1С было не при-чем. Я имею в виду, что у нас не будет обязатель-ства получения сертификатов для того, чтобы продавать коробки (по правилам, для того, чтобы продавать коробки, должно быть не меньше, чем два сертификата). У нас такой обязаловки не будет.

• Зачем еще? У 1С есть сборник задач. Но он ведь не удовлетворяет полностью потребностям об-щества. Он не все оценивает. Нужно иметь воз-можность, например, аттестовать специалиста только по одной подсистеме, только по работе с определенными механизмами. Сегодня разго-варивал с коллегой. Он говорит – «Не получил я сертификат. Потому что не сделал я задачу по ре-гистрам расчета». Но он с ними не работает. Так выдайте ему сертификат, где будет написано, что он умеет работать с такими механизмами, а с таки-ми не умеет. Вот это я имею в виду.

Что я имею в виду под более детальной сертификацией?

Около года назад крупная компания – не франчай-зи, заказала мне провести аттестацию их сотрудников. В итоге мы разработали таблицу на 18 листах, в кото-рой построчно было написано – «Умею делать вот это» – и по скольки балльной системе мы оцениваем это и сколько баллов уже набрано сотрудником.

В итоге мы каждого сотрудника оценили в нату-ральном выражении – в единицах ответа, и в процент-ном отношении – то есть, оценили эффективную результативность сотрудника по каждой компетен-ции.

На основе этой таблицы компетенций сотруд-никам была предложена система оплаты труда. При этом таблица осталась, естественно, у клиента и клиент сказал, что раз в год будет производиться пе-реаттестация. Если сотрудник вырастет за год на столько-то пунктов, мы ему увеличим зарплату на столько-то денег.

Нормальная, реальная мотивация. Правильно?

Как мы можем использовать этот результат оценки?

• Как я уже сказал – для внутреннего управления кадрами

• Для рекламы себя при трудоустройстве• Для рекламы компании перед заказчиком.

Приходит заказчик, а вы ему распечатку даете, и говорите: «наш сотрудник, который будет непо-средственно с вами работать, умеет работать вот с этим». И все – вопросов не будет. Допустим, клиент заказал обмен данными с сайтом. Нашли по этим листам, кто умеет работать – дали конкретного со-трудника этому заказчику. И клиент может потом претензию предъявить: «Вот вы мне сказали, что он умеет, а он не умеет. Почему?» И это будет уже адекватная претензия. Потому что вы не просто говорите «Он у нас аттестованный специалист», а говорите конкретно, по каким компетенциям он аттестован.

– 163 –


Соответственно, кто может владеть сертификатом?

• Компания• Физлицо• Передача сертификатов на любых договорных ус-

ловиях• И, что мне кажется довольно важным, раньше у 1С

можно было посмотреть, кто конкретно работает у франчайзи. Сейчас нельзя посмотреть. Только если ввести фамилию полностью, тогда узнаешь, есть у него сертификат или нет. А раньше это было открыто. Так вот, мне кажется, что ради реклам-ных целей, как самой компании, так и сотрудников этой компании можно сделать адаптивную систе-му – публичные сертификаты или приватные. То есть, есть информация об этом в открытом до-ступе или нет. Или, например, в открытом досту-пе нет, но вы можете дать клиенту специальный код, он его введет и увидит данные обо всей ва-шей таблице компетенций

• Специальный ресурс для управления сертифи-катами.

Адаптивная технология сдачи

У 1С есть только два формата сдачи сертификации – это либо в самой фирме 1С, либо тоже в фирме 1С, но через интернет – дистанционно, в терминале. Но ведь есть еще много вариантов:

• Допустим, компания хочет аттестовать свой отдел. Там 15 человек. Компания приглашает к себе в

отдел экзаменатора. Пускай он сам аттестует их. По-моему, это вполне хорошо.

• Можно у партнеров аттестовать. Например, стоит веб-камера, которая записывает результат сда-чи. А потом это все анализируется уже непосред-ственно экзаменатором

• И, в принципе, можно произвольно задать любые другие варианты сдачи, гарантирующие под-линность результата. Включая нотариуса, кон-кретно. Пришел нотариус и проконтролировал, что все там хорошо.

Кто бы мог проводить такую аттестацию?

• Ну вот, как я уже сказал, крупные фирмы уже это делают. Но они никогда не поделятся с вами свои-ми таблицами компетенций, и не раскроют кон-кретные результаты сдачи. Они этого не сделают, потому что они в это вложились

• Фирма 1С, на мой взгляд, такую серьезную атте-стацию проводить не будет. Ее вполне устраива-ет то, что есть сейчас

• Можно обратиться в непрофильное кадровое агентство. Заказать им разработку таких таблиц компетенций. И на основе них каким-то образом проводить сертификацию, но это невыгодно, дол-го и неэффективно. Потому что, скорее всего, бу-дет одноразово.

Альтернативная сертификация. Ценность сертификата

В связи со всем вышесказанным я считаю, что мож-но разработать альтернативную сертификацию. Но тут встает несколько серьезных вопросов. Например, ценность сертификата. Потому что, например, я, как физлицо, могу кому-то написать «Он все умеет». Но – к чему это приведет? Тот, кто меня не знает – для него это будет просто распечатанная бумажка без какой-ли-бо ценности.

– 164 –


• Поэтому нужна ценность сертификата, которая зависит от компании, которая его выдала. Не-подкупность и честная оценка

• Возможность проверки действительности сер-тификата. Бумажка бумажкой, но нужен какой-то ресурс, на котором можно проверить по номеру сертификата – кому он принадлежит и какой та-блице компетенций соответствует

• Признание сертификата крупнейшими игрока-ми рынка. То есть, если мы говорим про какую-то альтернативную сертификацию, естественно, ка-кие-то крупные и прогрессивные фирмы-франчай-зи должны его признавать. И это будет увеличи-вать его ценность.

Старт проекта «АА»

Теперь мы подходим к самому интересному. Вот сейчас я официально объявляю, что мы с коллегами хотим такой проект запустить.

Сейчас у нас есть только таблица компетенций, ко-торую писал я, и есть куча идей. И вот, когда мы начали работать с Фаритом Насиповым, то вот эта мысль про параллельную сертификацию у нас с самого начала была. Она витает уже давно и какие-то наработки у нас есть.

Соответственно, начиная с сегодняшнего дня, мы конкретно будем обращаться к фирмам-франчайзи для признания нашего сертификата, разрабатывать эти таблицы и проводить пробные аттестации. Кто хо-чет – коллеги, присоединяйтесь!

– 165 –

Мобильная платформа 1С: какие сложности вас ждут и как их обойти

Дмитрий ШерстобитовСооснователь компании DINEVA (Украина), которая занимается разработкой и внедрением программных решений для бизнеса

Наконец осознав важность игры на поле мобиль-ных технологий, известная нам компания из двух букв не так давно выпустила мобильную платформу 1С. Программистский мир «возрадовался» и принялся за создание мобильных приложений. Я не исключение. Но оказалось, что при декларируемых простоте и удоб-стве на этом тернистом пути нас, тем не менее, ждет много трудностей. Не знаю, как вы, а я провел много времени, пытаясь подружить 1С и Android. Данная ста-тья – итог этого веселого времяпрепровождения. Опи-сывать конкретные версии платформы я, конечно, не буду, ибо пока что, исправляя одну ошибку в старой версии, 1С умудряется допустить пять других ошибок в новой и совсем не хотят следить за выходом новых SDK от Google, которые применяются при компиляции приложения от 1С.

Я же остановлюсь на общих проблемах, с которы-ми столкнулся при работе с мобильной платформой, и вариантах их решения. Некоторые из предлагае-мых решений просты, в отдельных случаях придется попотеть. Как бы там ни было, работать с мобильной платформой можно, а мой опыт (и опыт других людей, которые делились им со мной), надеюсь, сделает ваше общение безболезненным. Или не сделает.

«В списках не значился»

Компания 1С не стала юлить и добровольно предо-ставила список того, что мобильная платформа, в от-личие от привычной конфигурации, не может в прин-ципе.

Официальный перечень функций, которые не под-держиваются мобильной платформой (копирую с http://v8.1c.ru/overview/Term_000000818.htm#1):

• используются не все классы объектов конфигура-ции;

• не используется механизм распределенных ин-формационных баз;

• не используется язык запросов и система компо-новки данных;

• используется ограниченный набор элементов формы;

• начальная страница содержит только одну форму; • не поддерживается пошаговая отладка.

А на картинке это выглядит вот так:

Уже из этой картинки видно, на какие ограничения вам придётся пойти ради достижения конечной цели.

Но давайте остановимся на некоторых пунктах под-робнее.

Отчеты

Итак, в мобильной платформе используются не все классы объектов конфигурации. Одно из самых груст-ных ограничений – это объект «Отчеты». Да, ваши глаза вас не обманывают. Накидать отчет от руки за 5 минут при помощи СКД не получится. Впрочем, если вам нуж-но сформировать очень сложный отчет, то на выручку придет Интернет, доступ к базе данных и веб-сервисы с веб-ссылками наперевес. Об этих хитрых ходах – ниже.

Синхронизация

Но представим себе, что мы очень пытливые и твер-до вознамерились создать отчет в условиях офлайна. Чтобы добиться этой цели, нам нужно пройти этап синхронизации, которая связана с механизмом рас-пределенных информационных баз. Думаю, не всем

– 166 –


читателям приходилось плотно заниматься распреде-ленными базами, поэтому остановимся на этой теме подробнее (знатоки могут смело пропускать данный параграф).

Берусь утверждать, что синхронизация, при помо-щи планов обменов ЦБ с мобильным приложением- не-тривиальна. Объясню почему.

Допустим, у вас имеется основная конфигурация УТ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.

Если вернуться к вопросу, который вынесен в за-головок параграфа, то в двух словах это выглядит так.

– 167 –

Дмитрий Шерстобитов Мобильная платформа 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С. Конечно, можно написать свои механизмы обмена, минуя планы обмена, но тогда придется контроль ак-туальности данных проводить самостоятельно.

– 168 –


Для работы с мобильным приложением нашу ЦБ на 8.х,7.7 нужно переводить на 8.3?

Тут все немного не так. Не стоит воспринимать мобильное приложение как узел ЦБ. Оно больше по-хоже на просто отдельную базу. Т.е. представьте себе, что вам необходимо связать вашу ЦБ с другой базой на платформе 8.3, т.е. если у вас ЦБ на 8.х, то можете использовать планы обмена (без использования РБД), web-сервисы, файловый обмен эксельками. А вот если у вас ЦБ на 7.7, то тут по идее ничего не изменится.

Я позволил себе нарисовать красивую картинку, которая демонстрирует всю простоту и элегантность решения.

Но в начале давайте определимся со структурой. Допустим, у нас компания, в которой есть отдел логи-стики и отдел торговых представителей. Усложним задачу: у каждого отдела своя конфигурация 1С для ра-боты на мобильном устройстве. Усложним задачу еще больше: сотрудники могут работать с 1С не только на мобильном устройстве, но и на ПК – в этой же базе дан-ных (как в тонком клиенте, так и в веб-браузере).

К примеру, если у товара много характеристик, тор-говому агенту удобнее ввести информацию на компью-тере, а с мобильного устройства он может просмотреть данные, отредактировать их и подтвердить. Аналогич-но с логистами: если сканируется приход – предпочти-тельней компьютер. Проверить наличие товара и ото-брать товар удобно и на телефоне.

В этом случае мы будем работать по такой схеме:

Как мы видим на рисунке, в центральной базе не будет почти никаких изменений, кроме новых планов обменов с промежуточными базами или (в случае с 7.7) каких-то своих вариантов обменов.

Промежуточные базы будут работать на платфор-ме 8.3 и передавать структуру конфигурации, а также данные мобильным устройствам.

Эта схема удобна тем, что при использовании пла-нов обмена между ЦБ и промежуточными базами, вы можете использовать схему РБД и/или прикрутить туда правила КД. В этом случае, возможно вам вообще не надо будет конфигурировать ЦБ.

А теперь давайте попробуем «упростить» схему: избавимся от промежуточных баз, чтобы все данные передавались сразу в ЦБ.

В этом случае картина такова:

Что особенного происходит в данном случае? У нас есть центральная база, в которой настроены планы обмена(соответственно мы «гоняем» данные из при-ложения в ЦБ и обратно), но одновременно у нас есть отдельная база, в которой мы пишем конфигурацию для мобильных телефонов.

Таким образом, ЦБ не должна располагаться имен-но на платформе 8.3, она может располагаться на лю-бой платформе, просто в планах обмена(или чем вы выберете делать обмен) нужно учитывать особенно-сти разных платформ.

Минусы такого подхода очевидны: необходимо постоянно переделывать конфигурацию, нужно соз-давать новые планы обменов и/или web-сервисы и т.д. Т.е. для применения этой схемы лучше иметь програм-миста в штате.

Какие типы поддержки (обновление, распро-странение) мобильной платформы предлагает 1С?

Начать надо с того, что есть два формата переноса конфигурации на мобильную платформу 1С (так как официального названия не нашел, то придумал свои):

• Фиксированная конфигурация• Произвольная конфигурация

На отличиях между ними нужно остановиться под-робнее, сразу хочу заметить, что переход от одного типа к другому – безболезненный.

Произвольная конфигурация

Произвольная конфигурация позволяет вам рабо-тать в одном мобильном приложении с несколькими разными базами, с разными конфигурациями,а также обновлять конфигурации через свой сервер.

Под нее программировать довольно просто: скон-фигурировали – опубликовали в web (в конфигурато-ре: Конфигурация – Мобильное приложение – Публико-вать; указываем имя публикации, отличное от имени публикации базы данных, если таковое имеется), за-тем нажали кнопку «Обновить» на телефоне. Или по-ставили галочку «Обновлять мобильные приложения» в конфигурации: тогда при входе пользователя в базу на телефоне (при наличии доступа к серверу конфигу-раций) мобильное приложение само обновит конфигу-рацию. Не нужно ничего компилировать и обновлять

– 169 –

Дмитрий Шерстобитов Мобильная платформа 1С: какие сложности вас ждут и как их обойти

вручную. Правда, в этом случае вы не сможете обно-вить мобильную платформу, не скинув ее отдельным файлом, или без помощи других сервисов.

Фиксированная конфигурация

Это конфигурация, скомпилированная до apk-фай-ла. Соответственно, если вы изменили что-то в конфи-гурации, вам необходимо всем пользователям отпра-вить этот файлик (вес –около 50Мб, стоит отметить, если мне не изменяет память, что маркеты уже давно переносят только измененные участки кода, что может значительно сократить размер файла при загрузке), и все должны переустановить приложение на телефоне. В этом случае обновится и платформа, и конфигура-ция. Данные, по идее, должны остаться.

Какой вариант распространения конфигурация лучше?

Если вы разработчик, который планирует написать конфигурацию для учета звезд во Вселенной и поде-литься ею со всеми живыми и не очень существами, то вам однозначно необходим вариант фиксированной конфигурации. Выбрав этот вариант, вы можете рас-положить свой apk-файл в интернет-магазинах типа GooglePlay, где приложение будет продаваться или рас-пространяться бесплатно (к слову, 1С еще не определи-лась с лицензиями до конца, но разрешать использо-вать без её ведома до 50 мобильных устройств). Если конфигурация обновляется, вы размещаете новый apk-файл в интернет-магазине, и вскоре он обновится у всех купивших приложение.

Если вы штатный программист, которому дали задание роботизировать группу торговых представи-телей, то ваш выбор однозначно должен пасть на ва-риант без компиляции. В этом случае вам достаточно установить на телефон мобильное приложение, кото-рое вы скачали, и добавить в него новую базу, прописав путь к опубликованной конфигурации. Этот вариант подходит также для отладки конфигурации до момен-та компиляции.

Не буду пересказывать статью «Пример создания конфигурации на Android из 1C 8.3»: по мере обновле-ния платформы она постоянно обновляется.

Что делать с iOS?

Тут все очень грустно и рассматривать этот вари-ант я не буду, в силу тех причин, что для работы надо или взламывать устройство (джейлбрэйк), или поку-пать дорогой Mac только для цели компиляции, а по-том еще проходить модерацию на AppStore и т.д. и т.п.

У меня Nokia 3310,я этим телефоном гвозди за-биваю, а к планшетам отношусь с недоверием, но хочу кодить под Android.

В этом случае вы можете скачать эмулятор AndroidBlueStacks(.com) и проводить тесты в нем. Достаточно установить эмулятор и два раза кликнуть

поapk-файлу. Только учтите: если вы захотите обнов-лять конфигурацию, которая опубликована на том же компьютере, не пытайтесь вбивать адрес 127.0.0.1, поскольку у эмулятора он свой. Узнайте IP своего ком-пьютера и убедитесь, что у него открыт порт 80 или какой вы там указали web серверу.

В последней версии этого эмулятора появилось много удобных вещей, например теперь вы можете от-крыть приложение во весь экран.

Я хочу работать с мобильными устройствами, но боюсь, что данные «уплывут» в Интернет.

Все решается просто. Вы можете «поднять» SSH-туннель (или VPN-канал) между своим телефоном и сервером. Для доступа в эту сеть используется специ-альный ключ, который генерируют на стороне серве-ра. Если у каждого менеджера будет свой ключ, то его (и менеджера, и его ключ) можно будет блокировать в любой момент.

Для поднятия безопасного соединения мы исполь-зуем программу BitviseTunnelier (бесплатна для инди-видуального использования). Ее мы устанавливаем на сервер, а рабочим компьютерам ставим клиент от этого же разработчика. На мобильных телефонах под управлением ОС Android мы используем SSH Tunnel, это приложение тоже бесплатно.

Таким образом данные «извне» не доступны. Кон-кретного человека можно в любой момент отключить от сети.

Резюме (час моей работы – бесценен).

Я остановился на основных проблемах, связанных с созданием конфигурации на мобильной платформе 1С и ее дальнейшим использованием. Платформа по-стоянно обновляется, и ситуация может значительно измениться, поэтому следите за релизами.

Издевался над вашей мечтой в светлое будущее с мобильной платформой от 1С – Дмитрий Шерстобитов (DitriX).

З.Ы. Но все же не все столь плохо, будущее одно-значно есть, ибо новый релиз мобильной платформы 1С (8.3.3.42) весит уже 23Mb, а это в два раза меньше начальных размеров. Приложение работает стабиль-нее, быстрее, долго висит в памяти телефона и т.д.

Documents

infostart Journal выпуск №2