귀하의 팀이 현재 시스템을 싫어합니까? 반란 없이 Odoo를 출시하는 방법은 다음과 같습니다.

당신은 전에 그것을 본 적이 있습니다. 누군가 공유 스프레드시트를 열었는데 데이터의 절반이 누락되었습니다. 창고 팀은 한 앱에서 재고를 추적하고 회계는 다른 앱을 사용하며 영업에는 이메일 스레드와 스티커 메모로 통합된 자체 "시스템"이 있습니다. 누구도 숫자를 믿지 않고, 모두가 해결 방법을 갖고 있으며, 회의마다 "그게 바로 우리가 일을 하는 방식입니다"라는 문구가 등장합니다.

불편한 진실은 다음과 같습니다. 귀하의 팀은 이미 귀하의 시스템이 손상되었음을 알고 있습니다. 그들은 매번 답답한 한숨을 쉬고, 모든 항목이 중복되고, "그냥 수동으로 할게요"라고 말하곤 했습니다. 문제는 Odoo가 필요한지 여부가 아닙니다. 먼저 상황을 악화시키지 않고 출시할 수 있는지 여부입니다.

이 가이드는 전환할 준비가 되었지만 결과를 두려워하는 비즈니스 소유자 또는 운영 리더를 위한 것입니다. 가장 큰 위험은 소프트웨어가 아니기 때문입니다. 전환하는 동안 팀의 신뢰를 잃고 있습니다.

현재 설정에 생각보다 비용이 많이 드는 이유

대부분의 회사는 비용이 눈에 잘 띄지 않기 때문에 고장난 시스템에 실제로 얼마나 많은 비용이 드는지 인식하지 못합니다. 이는 플랫폼 간에 데이터를 조정하는 데 소요된 초과 근무 시간으로 표시됩니다. 누군가 후속 조치를 잊어버렸기 때문에 판매 손실로 표시됩니다(CRM이 이메일과 동기화되지 않음). 주요 직원이 실제 업무를 수행하는 대신 도구와 싸우는 데 지쳐서 그만 두었을 때 나타납니다.

Panorama Consulting의 2024년 보고서에 따르면 조직의 53%가 단편화된 소프트웨어 시스템으로 인해 운영이 중단되었다고 보고했습니다. 그건 기술적인 문제가 아닙니다. 그것은 기술 마스크를 쓴 사람들의 문제입니다.

팀이 매일 무엇을 처리하는지 생각해 보세요. 영업 담당자가 거래를 성사시켰지만 세 군데에 고객 정보를 입력해야 합니다. 귀하의 회계사는 시스템이 서로 통신하지 않기 때문에 금요일 오후에 구매 주문서와 송장을 대조 확인하는 데 시간을 보냅니다. 창고 관리자는 공식 재고 수치를 신뢰하지 않기 때문에 "만약을 대비해" 개인 스프레드시트를 보관합니다.

이러한 마찰 지점 각각은 사기를 조금 더 약화시킵니다. 그리고 마침내 “새로운 시스템으로 전환하겠습니다”라고 발표해도 별로 흥분되지 않습니다. 당신은 두려움에 직면했습니다. 당신의 팀은 이전에 불에 탔기 때문입니다.

이것이 바로 롤아웃 전략이 소프트웨어 자체만큼 중요한 이유입니다. 잘못하면 아무도 사용하지 않는 값비싼 새 시스템을 갖게 될 것입니다. 올바르게 설정하면 그것 없이 어떻게 작업했는지 궁금할 것입니다.

올바른 파트너를 선택하면 모든 것이 달라집니다

대부분의 기업이 첫 번째로 중대한 실수를 저지르는 부분이 바로 여기에 있습니다. 즉, 구현을 내부적으로 처리하려고 합니다. IT 담당자가 몇 가지 YouTube 튜토리얼을 시청하고 커뮤니티 에디션을 다운로드한 후 모듈 구성을 시작합니다. 3개월 후, 아무도 Odoo 데모처럼 운영되지 않는 비즈니스를 위해 5년간의 고객 데이터를 마이그레이션하거나 워크플로를 사용자 정의하는 복잡성을 예상하지 못했기 때문에 프로젝트가 중단되었습니다.

경험이 풍부한 odoo 구현 회사와 협력하는 것은 단지 기술적 전문 지식에 관한 것이 아닙니다. 수십 건의 롤아웃이 옆으로 가는 것을 본 사람이 피해야 할 함정을 정확히 아는 사람을 갖는 것입니다. 올바른 파트너는 귀하의 가정을 거부하고, “필수” 기능 목록에 도전하고, “현재 프로세스가 문제이지 소프트웨어가 문제가 아닙니다.”와 같이 듣고 싶지 않은 말을 들려줄 것입니다.

잠재적인 파트너를 평가할 때 다음 세 가지에 집중하세요.

1. 산업 관련성. 제조 회사를 위해 Odoo를 구현한 파트너는 처음부터 설명하지 않고도 생산 계획, BOM 구조 및 품질 관리 워크플로우를 이해할 것입니다. 일반 ERP 컨설턴트는 가장 중요한 뉘앙스를 놓치는 경우가 많습니다.
2. 마이그레이션 경험. 데이터 마이그레이션은 구현이 끝나는 곳입니다. 더티 데이터, 중복 기록, 레거시 시스템 형식을 어떻게 처리하는지 구체적으로 물어보세요. 대답이 모호하면 계속 찾아보세요.
3. 출시 후 지원. 가동 후 처음 60일은 혼란스럽습니다. 파트너는 버그 수정, 사용자 지원 및 불가피한 "이 워크플로를 잊어버렸습니다" 발견에 대한 명확한 계획을 가지고 있어야 합니다.

좋은 파트너는 팀과 프로젝트의 복잡성 사이에서 완충 역할도 합니다. 창고 관리자는 API 통합을 이해할 필요가 없습니다. 그들에게는 함께 앉아서 그들이 실제로 어떻게 작동하는지 지켜보고, 그 반대가 아닌 그에 맞게 시스템을 구성할 사람이 필요합니다.

대부분의 기업이 생략하는 출시 전 작업

캐비닛을 먼저 치우지 않고는 부엌을 개조할 수 없습니다. 그러나 기업들은 항상 손상된 프로세스 위에 ERP 시스템을 구현하려고 합니다.

Odoo를 만지기 전에 2~4주 동안 화려하지 않지만 필수적인 준비 작업을 하세요. 이는 원활한 출시와 재해 사례를 구분하는 단계입니다.

이상적인 워크플로가 아닌 실제 워크플로를 매핑하세요. 일이 어떻게 작동해야 하는지 문서화하지 마세요. 현재 실제로 어떻게 작동하는지, 해결 방법 등을 문서화하세요. 당신이 발견한 것에 놀라게 될 것입니다. 제가 함께 일했던 한 물류 회사는 공식 소프트웨어가 분할 배송을 처리할 수 없었기 때문에 파견 팀이 Google 스프레드시트에 전체 섀도우 시스템을 구축했다는 사실을 발견했습니다. 해당 Google 시트는 Odoo 사용자 정의의 청사진이 되었습니다.

고급 사용자를 조기에 식별하십시오. 모든 부서에는 다른 사람들이 막힐 때 찾아가는 한두 명의 사람이 있습니다. 이들은 구현 챔피언입니다. 최종 테스터로서가 아니라 새로운 워크플로우의 공동 디자이너로서 첫날부터 참여하게 하십시오. 창고 책임자가 재고 모듈 구축을 도우면 이를 소유하게 됩니다. 그것이 그들에게 전달되면 그들은 그것을 분개합니다.

마이그레이션하기 전에 데이터를 정리하세요. 이것은 ERP 프로젝트에서 가장 지루한 부분이자 가장 중요한 부분입니다. 기존 데이터에 대한 감사를 실행하고 어려운 질문을 해보세요.

• 중복된 고객 기록이 몇 개나 존재합니까?
• 누군가가 마지막으로 공급업체 연락처 정보를 확인한 때는 언제입니까?
• 제품 SKU는 모든 시스템에서 일관됩니까, 아니면 창고에서 회계와 다른 코드를 사용합니까?
• 거래 내역은 얼마나 오래 전으로 거슬러 올라가야 합니까? (힌트: 아마도 당신이 생각하는 것만큼은 아닐 것입니다.)

가비지 데이터를 클린 시스템으로 마이그레이션하면 가비지로 가득 찬 클린 시스템이 제공됩니다. 먼저 청소를 해보세요.

리더십에 대해 정직한 기대치를 설정하십시오. 중견 기업의 Odoo 출시에는 일반적으로 3~6개월이 소요됩니다. 블로그 게시물 하나가 무엇을 약속했든 3주는 아닙니다. 전환 중에는 생산성이 저하됩니다. 사람들은 좌절할 것이다. 최고 경영진이 첫날부터 모든 것이 완벽하게 실행되기를 기대한다면 이미 실패한 것입니다. 현실적인 일정을 조정하고 전사적으로 이를 전달합니다.

팀을 잃지 않고 롤아웃하기

여기서는 프로젝트의 기술적인 측면보다 사람의 측면이 더 중요합니다. 시스템을 완벽하게 구성해도 팀이 사용을 거부하면 여전히 실패할 수 있습니다.

단계적으로 진행하십시오. 밤새 스위치를 뒤집지 마십시오. 빅뱅 롤아웃(오래된 시스템을 종료하고 월요일 아침에 완전히 가동하는 것)이 효율적으로 들립니다. 실제로 이는 팀에 끔찍한 일이며 단일한 대규모 실패 지점을 생성합니다. 대부분의 회사에서는 단계적 접근 방식이 더 효과적입니다.

하나의 부서 또는 하나의 모듈로 시작하세요. 먼저 Odoo에 대한 회계를 확인하고, 거친 부분을 찾고, 정리한 다음, 재고로 확장하도록 하세요. 그런 다음 판매. 그런 다음 구매합니다. 각 단계는 자신감을 구축하고 다음 그룹을 도울 수 있는 내부 옹호자를 창출합니다.

소프트웨어 기능이 아닌 실제 작업을 위해 교육하세요. 거의 모든 사람들이 저지르는 훈련 실수는 다음과 같습니다. 그들은 사람들에게 소프트웨어 사용 방법을 가르칩니다. 여기를 클릭하고 거기에 데이터를 입력하고 이 보고서를 실행하세요. 그것은 교육이 아닌 소프트웨어 데모입니다.

효과적인 훈련은 다르게 보입니다. 팀이 실제로 직면하는 시나리오를 중심으로 구축되었습니다.

• "주문이 확인된 후 고객이 주문을 변경하려고 전화했습니다. Odoo에서 이를 처리하는 방법은 다음과 같습니다."
• "공급업체가 잘못된 수량을 배송했습니다. 불일치를 기록하고 신용 전표를 발행하는 방법은 다음과 같습니다."
• "어떤 구매 주문이 연체되었는지 확인해야 합니다. 매일 아침 사용할 대시보드는 다음과 같습니다."

사람들이 시스템이 일상의 특정 문제를 어떻게 해결하는지 보면 저항이 빠르게 감소합니다. 그들은 Odoo를 "배워야 할 또 다른 것"으로 보지 않고 "마침내 내 일을 더 쉽게 만들어 주는 것"으로 보기 시작합니다.

불만사항을 위한 안전한 공간을 만드세요. 이것은 부드러워 보이지만 실용적입니다. 사람들이 판단 없이 문제, 혼란, 좌절감을 보고할 수 있는 전용 Slack 채널이나 매주 15분 스탠드업을 설정하세요. 정식 티켓팅 시스템이 아닙니다. 진짜 인간적인 대화.

이 작업을 수행하면 두 가지 일이 발생합니다. 첫째, 작은 문제가 큰 문제로 커지기 전에 잡아냅니다. 둘째, 팀이 자신의 의견을 듣고 있다고 느낍니다. 그리고 자신의 의견을 듣고 있다고 느끼는 사람들은 새로운 워크플로를 배우는 데 따른 불편함을 훨씬 더 기꺼이 극복하려고 합니다.

작은 승리를 공개적으로 축하하세요. 수동으로 데이터를 다시 입력하지 않고 첫 번째 자동 송장이 발행되면 소음을 내십시오. 3년 만에 재고실적이 시스템과 일치하면 회사 전체에 알린다. 이러한 순간은 추진력을 형성하고 사람들에게 왜 이런 일을 겪고 있는지 상기시켜줍니다.

가동 후 처음 60일

라이브는 결승선이 아닙니다. 출발선입니다. 처음 60일은 사람들이 다시 스프레드시트로 돌아가면서 구현이 뿌리를 내리거나 조용히 포기되는 기간입니다.

다음과 같은 일이 일어날 것으로 예상하십시오.

1. 누군가가 당신이 잊어버린 작업 흐름을 찾아줄 것입니다. 분기별 커미션 계산일 수도 있고 도매 고객과 소매 고객의 반품이 처리되는 방식일 수도 있습니다. 이는 모든 롤아웃에서 발생합니다. 이 단계에서 대응적인 구현 파트너를 확보하는 것은 선택 사항이 아닙니다. 그것은 필수적입니다.
2. 처음에는 속도가 느려집니다. 이전 시스템에서 팀이 2분씩 걸렸던 작업이 처음 몇 주 동안 Odoo에서는 5분이 걸릴 수 있습니다. 이것은 정상입니다. 시스템 결함이 아니라 학습 곡선입니다. 6주차에는 동일한 작업에 30초가 소요됩니다.
3. 한두 사람이 다른 사람들보다 더 강하게 저항할 것입니다. 대개는 이전 시스템의 "전문가"였던 사람입니다. 그들의 지위는 모든 해결 방법을 알고 있는 사람이라는 것과 관련이 있었습니다. Odoo는 해결 방법을 더 이상 사용하지 않게 만들었고 이는 위협처럼 느껴집니다. 추가 교육 이메일이 아닌 직접적인 대화로 이 문제를 처리하세요.
4. 모든 것을 즉시 맞춤설정하고 싶을 것입니다. 이 충동에 저항하십시오. 사용자 정의 모듈이나 주요 변경 사항을 요청하기 전에 최소 90일 동안 표준 구성을 실행하십시오. 실제로 변경해야 할 사항과 익숙하지 않은 부분을 파악하려면 실제 사용 데이터가 필요합니다.

이 기간 동안 문제, 기능 요청 및 프로세스 공백에 대한 실행 로그를 유지하십시오. 구현 파트너와 함께 매주 검토하세요. 일부 항목은 사람들이 편안해지면 저절로 해결됩니다. 다른 것들은 실제 구성 변경이 필요합니다. 이러한 결정을 뒷받침할 데이터가 있으면 ERP 예산을 낭비하는 맞춤화 나선형을 방지할 수 있습니다.

실제로 작동하는지 측정

재미로 Odoo를 구현한 것이 아닙니다. 특정 문제를 해결하기 위해 그렇게 했습니다. 따라서 이러한 문제를 직접 측정하십시오.

가동하기 전에 기준을 문서화하세요.

• 월간 장부를 마감하는 데 얼마나 걸리나요?
• 현재 주문에서 배송까지의 주기는 얼마나 됩니까?
• 귀하의 팀은 수동으로 데이터를 입력하거나 조정하는 데 일주일에 몇 시간을 소비합니까?
• 재고 수량은 시스템 기록과 얼마나 자주 일치합니까?

그런 다음 출시 후 30일, 60일, 90일에 동일한 측정항목을 확인하세요. 90일까지 의미 있는 움직임을 확인해야 합니다. 그렇지 않으면 지금 다음 분기가 아닌 구현 중 일부에 주의가 필요한 것입니다.

한 제조 고객은 Odoo 전후의 월말 마감 프로세스를 추적했습니다. 이전: 영업일 기준 11일, 3명이 초과 근무를 했습니다. Odoo에서 90일 후: 영업일 기준 5일, 동일한 3명이 오후 5시에 출발합니다. 그것은 소프트웨어 측정항목이 아닙니다. 그것은 삶의 질을 측정하는 지표입니다. 그리고 이는 구현이 작동 중임을 알려주는 숫자입니다.

누구도 후회하지 않는 출시

Odoo를 성공적으로 구현한 모든 회사는 다음과 같이 말합니다. "우리는 이 작업을 2년 전에 했어야 했습니다." 그리고 실패한 회사를 겪은 모든 회사는 "우리는 서둘렀습니다."라고 말합니다.

이 두 가지 결과의 차이는 소프트웨어에 따라 결정되는 경우가 거의 없습니다. Odoo는 복잡한 제조, 다중 창고 물류, 국제 회계 및 그 사이의 모든 것을 처리할 수 있습니다. 기술이 작동합니다.

성공과 실패를 구분하는 것은 인간적인 측면입니다. 이전에 이 일을 해본 적이 있고 복잡성을 존중하는 파트너를 선택하는 것입니다. 팀이 분노가 아닌 주인의식을 느낄 수 있을 만큼 일찍 팀을 참여시키는 것입니다. 일정에 대해 정직하고, 학습 곡선에 인내심을 갖고, 첫날에 모든 것을 사용자 정의하지 않는 것에 대해 규율을 유지하는 것입니다.

귀하의 팀은 이미 현재 시스템을 싫어합니다. 그들은 더 나은 것을 준비하고 있습니다. 그들의 시간, 전문성, 인내심을 존중하는 롤아웃을 제공하면 그들이 단지 Odoo를 채택하지 않을 것입니다. 그들은 그것을 옹호할 것입니다.