Как я на первом курсе колледжа оптимизировал работу в канадском офисе HP

Гайд от студента из России о том, как можно организовать стажировку в Канадском представительстве HP, если вы озадачены её эффективностью.

Привет! Меня зовут Лев, всего год назад я поступил в Humber College в Торонто, и моя жизнь сильно изменилась. Я хочу поделиться опытом стажировки в крупной компании в Торонто и рассказать о ее результатах.

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

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

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

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

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

В начале Апреля этого года во время карантина, дома было скучно. Учеба неожиданно и резко кончилась, а вместе с ней и проживание в общежитии. Деньги постепенно заканчивались, и я решил заняться своей стажировкой. Благо на моей программе проходить ее можно в любое время (optional co-op).

Тогда по знакомству (такие в Америке / Канаде происходят постоянно) я устроился на полную занятость QA специалистом с минимальной з/п (14$ в час).

С первого же дня стало понятно, что работенка не пыльная, но рутинная. В мои обязанности входило: визуальный осмотр внешнего состояния ПК, bios тестирование компонентов и проверка windows. После чего ПК нужно было протереть, пробить по штрих коду в системе и отправить на следующую станцию для подготовки к отправке (OBA). Так в среднем 50 раз в день…

Рутина страшная, было понятно, что так научиться чему-либо не получится. Через 1,5 недели рутина меня начала просто убивать, синяки под глазами, мысли до работы и после о том, зачем это всё, ощущение безысходности и т.д. Тогда я решил «взять быка за рога» и разобраться в работе офиса, чтобы провести время не зря, не скучно, а возможно и что-нибудь улучшить.

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

Весь комплекс работает по принципу конвейера с персональными компьютерами (далее ПК). Основное здание делится на 3 зоны / участка.

1 — (receiving) прием ПК, распределение по типу ремонта, регистрация в системе.

2 — (repair and QC) ремонт компьютеров и 3‑х уровневый контроль качества.

3 — (shipping) отправка отремонтированного ПК обратно владельцу.

В день в среднем, приходит и отправляется обратно клиентам 130 ПК. Мой участок (2 — repaire and QC) работал следующим образом: Техники получали компьютеры (Repair), ремонтировали их и отправляли на станцию проверки качества (QC), где компьютеры сначала проверялись, а затем подготавливались к следующему этапу (OBA) и переходили в отдел отправки.

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

Например:

Эти вопросы я начал задавать сначала своим коллегам и руководителю (тим лид), а после и нашему менеджеру. Иногда я получал комментарии, которые действительно объясняли причину, но часто были и такие: — «We always do this way because it works» — It is what it is. От специалиста к специалисту подобные формулировки менялись и становились более сглаженными, но смысл оставался прежним.

Через 3 недели я собрал все содержательные ответы и решил разобраться что делать с вопросами без ответов. Я подготовился и пошел на «серьезный» разговор к менеджеру, который уже знал, что я задаю много вопросов. Я задал свои вопросы и показал собранный материал. А он рассказал о том какие проблемы наблюдаются в офисе из недели в неделю и показал отчётность.

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

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

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

- Essential Guide to Operations Management (David Bamford & Paul Forrest) — книга полная разборов разных тактик и методов с примерами в конце каждой главы, именно здесь я нашел ответы на все основные вопросы по моему проекту.

- Essential Tools For Operations Management (Simon A. Burtonshow-Gunn) — своего рода словарь управленца, однако, для людей знакомых с основами менеджмента, как и мне для практических задач, эта книга малополезна.

- Management and Supervision for Working Professionals — Volume 1 (Herman Koren) — учебник, из библиотеки UofT. Неожиданно хорошо помогает понять принципы работы иерархии и обязанности сотрудников в компании.

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

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

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

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

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

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

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

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

Посмотрев на мой план, менеджер заметно растерялся, до этого момента он общался со мной как с ребенком в возрасте «Почему”. Он сделал глаза по 5 копеек и сказал “Nice». После этого мы смогли обсудить детали проблем и решений, я смог показать свои знания из книг и хорошее понимание нашего процесса и коллектива. Менеджер засветился моей идей, он помог мне сделать план и она стала нашей.

План работы состоял из 5 пунктов:

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

Задача замеров (сбора и анализа данных) состояла из 2‑х частей:

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

На следующий день после разговора я решил попробовать замерить свое собственное время простоя с помощью обычного таймера на рабочем ПК. В результате замеров в Четверг моё время простоя было ровно 1 час 56 мин (¼ рабочего дня) и это при 53 проверенных компьютерах за день — самый высокий показатель среди всех QA. Сказать, что результат меня впечатлил, ничего не сказать.

Однако, подобный метод абсолютно точно не годился для моих коллег. Обязательно нужно было вести записи, чтобы иметь структуру и архив такого большого объёма информации, в том числе для того, чтобы можно было вести проверку. Для этого было принято решение использовать Фотографию рабочего дня (Activity Sampling Observation).

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

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

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

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

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

Очень важно было сохранять дружественный тон, потому что иначе это могло привести к тому что я вел бы себя «bossy» и просто неприятно. Таким образом в течение недели я по одному подключил всех QA специалистов. Моя тактика сработала и по результатам недели я получил 15 полных, правильно и честно заполненные бланков.

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

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

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

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

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

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

В итоге финальный план был одобрен вышестоящим начальством в том числе исполнительным директором компании к внедрению. Так же моя идея послужила своего рода MVP версией крупного продукта. После ее тестирования запланировали внедрить систему в остальных подразделениях компании. Я получил отличное Рекомендательное письмо и прекрасный опыт!

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

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

Я планировал в Августе улететь в Москву увидеться с семьей. Как и многие в 2020 году я никуда не полетел, сижу в новой квартире в районе Lakeshore. С отличным видом на CN Tower и озеро. Проедаю заработанные деньги: )

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

LinkedIn: https://www.linkedin.com/in/leofedoseev/

Facebook: https://www.facebook.com/fedoseev.lev

Email: lev.fedoseev@gmail.com