핵심노트 · 주제 05-01

IT 비즈니스

이게 뭔가요?

IT로 누구의 어떤 문제를 해결하고, 처리 시간·비용·오류를 줄이거나 고객에게 필요한 새 서비스를 제공할 수 있을지 판단하는 방법을 배웁니다. 식당 예약 앱을 생각한다면 먼저 고객이 왜 오래 기다리는지 살펴보고, 예약 방식이 대기 시간을 줄이는 데 도움이 될지 확인하는 일입니다.

왜 배우나요?

앱을 만들었다고 저절로 업무가 좋아지지는 않습니다. 기다림의 원인이 음식 준비에 있다면 예약 기능만으로는 부족할 수 있습니다. 현재 업무에서 잘되는 부분과 비효율을 구분하고, 필요한 곳에 IT를 적용한 뒤 시간·비용·만족도가 실제로 나아졌는지 확인하기 위해 배웁니다.

주문 취소를 줄이거나 처리 시간을 단축하는 것처럼 개선할 결과를 먼저 정합니다. 현재 업무에서 그 결과를 얻지 못하는 원인을 찾은 뒤 IT로 해결할 부분을 고릅니다.

교재 개념의 뜻을 설명하고, 가상 업무에서 언제 왜 쓰는지 풀어 쓴 자체 해설입니다. 먼저 설명과 예시를 읽고, 확인 질문에 자신의 말로 답해 보세요. 각 항목의 관련 교재 내용에서 단원과 교재 페이지를 확인할 수 있습니다. 20개 노트는 교재 전체 요약이나 시험 중요도 순위가 아니며, 주제 끝의 추가 학습 내용도 함께 확인하세요.

1. 비즈니스와 IT의 연계 — 시스템 도입으로 개선할 업무를 정한다

비즈니스와 IT의 연계는 사업에서 이루려는 목표에 맞춰 시스템의 기능과 투자, 담당자의 일을 정하는 것입니다. ‘앱을 만들자’에서 시작하기보다 ‘무슨 문제를 줄이려고 앱을 만드는가’를 먼저 확인합니다.

예를 들어 품절 상품의 주문을 받아 취소하는 일이 잦다면, 주문 전에 재고를 확인하고 부족한 상품을 보충하는 업무가 필요합니다. IT는 그 확인과 알림을 돕도록 설계합니다. 앱 완성과 주문 취소 감소는 다른 결과이므로 공개 후 실제 취소가 줄었는지도 확인해야 합니다.

가상 업무 예시

매장에서 재고가 없는 상품의 주문을 받았다가 취소하는 일이 반복된다고 합시다. 점장은 이런 취소를 줄이려고 주문 전에 재고를 확인하는 기능과 부족한 상품을 알려 주는 기능을 검토합니다. 앱을 만든 뒤에는 도입 전후의 품절 취소 건수를 같은 기준으로 비교해 실제로 줄었는지 확인합니다.

생각해 볼 질문
이 시스템을 도입해서 업무의 어떤 문제를 해결하려고 하나요? 도입 전후 무엇을 비교하면 개선됐는지 알 수 있나요?

2. As-Is와 To-Be — 현재와 목표의 차이를 구체화한다

As-Is는 현재 상태, To-Be는 앞으로 만들려는 상태입니다. ‘신청을 처리하는 데 사흘 걸린다’가 현재라면 ‘하루 안에 처리한다’가 목표가 될 수 있습니다. 두 상태의 차이가 해결할 문제를 구체적으로 보여 줍니다.

그러나 차이를 적었다고 원인을 찾은 것은 아닙니다. 담당자가 입력하느라 오래 걸리는지, 승인자가 자리를 비웠는지, 서류가 빠져 다시 받는지 조사해야 합니다. 원인이 다르면 입력 화면 개선, 대리 승인, 제출 안내처럼 필요한 해결 방법도 달라집니다.

가상 업무 예시

출장자가 떠나기 전에 교통편을 예약해야 하는데 비용 승인이 사흘 걸려 출발 전날에야 표를 삽니다. 목표를 ‘오전에 접수한 정상 신청은 당일 승인’으로 정한 뒤 시간을 재니 입력은 10분이고 팀장 부재로 이틀을 기다렸습니다. 회사는 입력 화면을 새로 만드는 대신 부재 시 대리 승인자를 지정하고 실제 처리 시간을 다시 측정합니다.

생각해 볼 질문
지금 업무는 얼마나 걸리고, 얼마나 줄이려고 하나요? 지연 원인을 실제 처리 기록이나 현장 관찰로 확인했나요?

3. 가치사슬 — 각 업무가 고객에게 주는 이익을 살핀다

가치사슬은 제품과 서비스가 고객에게 이르기까지 어떤 활동이 가치를 만드는지 살펴보는 틀입니다. 재료를 받고 제품을 만들고 판매·배송하는 주요활동뿐 아니라 사람을 채용하고 기술을 개발하는 지원활동도 함께 봅니다.

가치는 단순히 일이 빨라졌다는 뜻이 아닙니다. 고객이 필요한 제품을 제때 받고 문제를 해결할 수 있어야 합니다. 본사의 보고 확인은 빨라져도 매장이 같은 자료를 두 번 입력하느라 고객 응대를 못 한다면 전체 활동을 다시 살펴야 합니다.

가상 업무 예시

가구 업체는 온라인 주문은 빨리 받지만 자재 입고와 생산 계획을 따로 관리해 배송 약속을 자주 어깁니다. 팀은 구매·생산·판매·배송의 연결을 따라가며 재고와 생산 가능일을 확인한 뒤 배송일을 제시하도록 바꿉니다. 고객이 제때 가구를 받으려면 판매 화면만 개선할 것이 아니라 뒤에서 약속을 지킬 활동도 함께 맞춰야 합니다.

생각해 볼 질문
업무 방식을 바꾸면 고객과 각 부서에 어떤 이익이 생기나요? 다른 담당자의 입력이나 확인 작업이 늘지는 않나요?

4. 현장과 기존 절차 — 바꾸기 전에 이유를 이해한다

업무 프로세스는 일을 시작해서 결과를 낼 때까지의 활동 순서입니다. BPR은 비용·품질·서비스·속도를 크게 개선하려고 이 업무 흐름을 근본적으로 다시 설계하는 접근입니다. 작은 화면 수정이나 단순한 절차 생략을 모두 BPR이라고 부르지는 않습니다.

크게 바꾸려 해도 현재 절차가 왜 있는지부터 이해해야 합니다. 출고 전에 두 사람이 확인하는 일이 느려 보여도 과거의 오배송을 막으려고 만든 절차일 수 있습니다. 무엇을 대조하는지 확인하고, 새 방법으로 같은 위험을 줄일 수 있는지 시험한 뒤 바꿉니다.

가상 업무 예시

출고 전 두 사람이 확인하는 절차가 느려 보일 수 있습니다. 과거의 오배송을 막기 위한 단계라면 바로 없애기보다 무엇을 대조하는지 알아보고, 바코드 확인으로 같은 위험을 줄일 수 있는지 현장과 검증합니다.

생각해 볼 질문
없애려는 절차는 어떤 사고를 막고 있으며 대안은 그 역할을 대신합니까?

5. 요구사항 — 목표를 확인 가능한 동작으로 바꾼다

요구사항은 시스템이 어떤 일을 하고 어떤 조건을 지켜야 하는지 적은 것입니다. ‘승인을 전산화한다’만으로는 부족합니다. 누가 신청하고 누가 승인하는지, 승인자가 없을 때는 어떻게 하는지, 어떤 결과가 나와야 하는지를 정해야 합니다.

외부 업체에 개발을 맡길 때 이런 조건을 제안요청서로 전달하고, 납품을 받아들일 기준도 합의합니다. 예를 들어 신청자가 수정 후 다시 제출할 수 있어야 한다면 실제 신청·반려·수정·재승인을 해 보며 확인합니다. 업무를 아는 발주자와 만드는 개발자가 같은 결과를 기대하도록 맞추는 과정입니다.

가상 업무 예시

회사 출장비 신청을 전산화하면서 ‘팀장 승인’만 적었습니다. 개발자는 팀장이 없으면 대기하도록 만들었지만 현업은 지정된 대리자가 승인하기를 기대했습니다. 발주 담당자는 부재 조건, 대리자 지정, 승인 기록을 요구사항에 넣고 ‘팀장 부재 중 신청’으로 납품을 확인합니다. 원하는 동작을 확인 가능한 상황으로 합의한 것입니다.

생각해 볼 질문
누가 어떤 순서로 신청하고 승인해야 하나요? 어떤 결과가 나오면 요청한 기능이 완성됐다고 인정할지 합의했나요?

6. ISP와 투자 우선순위 — 도입·교육·운영 비용을 함께 계획한다

ISP는 정보전략계획입니다. 현재 업무와 IT가 어떤 상태인지 조사하고, 앞으로의 목표를 위해 무엇을 어떤 순서로 도입할지와 필요한 비용을 정합니다.

예산이 한정돼 있다면 보기 좋은 통계 화면과 주문 누락 방지 중 어느 일을 먼저 할지 골라야 합니다. 지금 생기는 손실과 기대 효과를 비교하고, 정확한 자료 수집처럼 먼저 끝나야 할 일도 찾습니다. 개발비만 계산하면 교육·자료 정리·운영 비용이 빠질 수 있으므로 실제 사용까지 필요한 일을 함께 계획합니다.

가상 업무 예시

유통사는 수요 예측과 재고 통합을 모두 도입하고 싶지만 지점마다 상품 코드가 달라 판매량을 합칠 수 없습니다. 예측 도구를 먼저 사도 믿을 만한 입력 자료를 만들기 어렵습니다. 담당자는 상품 코드 정리와 담당자 지정, 재고 통합, 수요 예측 시범 운영 순으로 계획하고 데이터 정리·교육·운영 비용도 예산에 넣습니다.

생각해 볼 질문
예산과 인력을 이 과제에 먼저 쓰면 어떤 과제를 미뤄야 하나요? 도입·교육·운영 비용까지 고려해도 기대 효과가 더 큰가요?

7. IT 거버넌스 — 결정권과 책임을 분명히 한다

IT 거버넌스는 IT에 관한 중요한 결정을 누가 어떤 기준으로 내리고 결과에 책임질지 정하는 체계입니다. 부서 의견을 모으는 것만으로 끝나지 않고 사업 목표·비용·위험을 기준으로 선택하고 확인할 사람을 정합니다.

영업팀은 주문을 바로 받고 싶지만 재무팀은 이전 대금을 내지 않은 고객의 주문을 막고 싶을 수 있습니다. 이때 개발자가 마음대로 한쪽을 고르기보다 사업 책임자가 보류 조건과 예외 승인자를 정해야 합니다. 개발팀은 그 결정을 프로그램으로 구현합니다.

가상 업무 예시

영업팀은 주문을 바로 확정하길 원하지만 재무팀은 이전 대금을 내지 않은 고객의 주문을 보류하길 원할 수 있습니다. 사업 책임자는 미납액이 얼마일 때 보류할지, 예외 주문은 누가 승인할지 두 부서와 정합니다. 개발팀은 그 기준을 기능으로 구현합니다.

생각해 볼 질문
부서의 요구가 충돌할 때 누가 어떤 기준으로 최종 결정합니까?

8. PI와 변화의 정착 — 새 방식으로 일하게 한다

PI는 프로세스 혁신입니다. 업무 순서뿐 아니라 조직의 역할과 관리 방법을 함께 개선하며 IT를 활용합니다. 새 시스템을 설치하는 것만으로 사람들이 일하는 방식이 저절로 바뀌는 것은 아닙니다.

온라인 신청을 만들고도 종이를 따로 내야 한다면 직원은 일을 두 번 합니다. 종이를 언제부터 그만 받을지, 누가 온라인으로 확인할지, 예외와 문의는 누가 처리할지 정해야 합니다. 새 방식을 거부하는 사람에게 의지가 없다고 단정하기 전에 실제로 어떤 일이 더 번거로워졌는지도 확인합니다.

가상 업무 예시

새 신청 시스템을 도입하면서 종이 제출도 계속 요구하면 직원은 일을 두 번 합니다. 전환 기간과 예외를 정하고, 새 방식으로 처리해도 업무가 인정되도록 관리자의 확인 방식까지 바꿉니다.

생각해 볼 질문
직원이 새 시스템만으로 업무를 끝낼 수 있나요? 종이 제출 같은 중복 절차를 없애고 문의를 처리할 담당자는 정했나요?

9. KPI와 성과 검증 — 목표 달성도를 확인한다

KPI는 핵심성과지표로, 목표에 얼마나 가까워졌는지 확인하는 측정값입니다. CSF는 핵심성공요인으로, 목표를 이루려면 특히 잘해야 하는 일을 뜻합니다. 신속한 신청 처리가 중요한 일이라면 신청부터 결과 통보까지 걸린 시간을 지표로 삼을 수 있습니다.

측정값은 목표와 연결돼 있어야 합니다. 접속 횟수가 늘었다고 신청 처리가 빨라졌다고 말할 수는 없습니다. 도입 전후를 같은 기준으로 비교하고, 처리 시간은 줄었지만 잘못된 승인이나 재작업이 늘지는 않았는지도 함께 봅니다.

가상 업무 예시

출장비 정산 시스템을 도입한 뒤 담당자는 로그인 수가 늘었다고 보고했습니다. 원래 목표는 직원이 돈을 돌려받는 시간을 줄이는 것이었습니다. 회사는 신청부터 입금까지의 기간과 증빙 보완으로 되돌아간 비율을 도입 전후 같은 기준으로 비교합니다. 화면 사용이 늘었다는 사실과 정산 업무가 나아졌다는 판단을 분리합니다.

생각해 볼 질문
시스템 도입 전후의 처리 시간과 오류 건수는 어떻게 달라졌나요? 빨라진 대신 오류가 늘지는 않았나요?

10. PDCA — 운영 결과를 다음 개선에 반영한다

PDCA는 계획(Plan)·실행(Do)·점검(Check)·조치(Act)를 반복하며 개선하는 방법입니다. 처음 세운 방법이 맞는지 실행 결과로 확인하고, 효과가 있으면 운영 기준에 반영하며 문제가 있으면 수정합니다.

품절을 줄이려고 발주량을 늘렸다고 합시다. 실행 후 품절은 줄었지만 팔리지 않은 재고가 늘었다면 성공이라고 끝낼 수 없습니다. 품절과 남는 재고를 함께 점검하고 발주 기준을 조정합니다. 이렇게 확인한 결과가 다음 계획의 근거가 됩니다.

가상 업무 예시

매장의 품절을 줄였더니 이번에는 남는 재고가 늘었다고 합시다. 시스템 도입을 완료했다고 끝내지 않고 발주 기준과 판매 예측의 가정을 다시 확인합니다. 품절과 재고 부담을 함께 보며 기준을 조정합니다.

생각해 볼 질문
운영 중 발견한 문제를 누가 모으고 검토하나요? 발주 기준이나 시스템 기능을 언제 어떻게 수정할지 정했나요?

11. 재무적 성과평가 — 비용과 순효과를 비교한다

재무적 성과평가는 투자에 든 비용과 얻은 효과를 돈으로 비교하는 것입니다. ROI는 비용에 비해 순효과가 얼마나 되는지 보는 비율입니다. 이 가상 예에서 총비용 100만 원, 금전적 효과 130만 원이라면 순효과는 30만 원이고 ROI는 30 ÷ 100 × 100 = 30%입니다.

NPV는 순현재가치입니다. 미래에 받을 돈과 지출할 돈을 현재 가치로 바꿔 더하므로 언제 효과가 생기는지도 반영합니다. 주문 수가 늘었다는 이유만으로 수익성이 좋아졌다고 할 수는 없습니다. 배송비와 운영비도 계산하고, 고객 만족처럼 돈만으로 설명하기 어려운 효과는 별도로 확인합니다.

가상 업무 예시

무료 배송 실험으로 한 달 추가 주문에서 상품 원가를 뺀 이익이 130만 원 생겼지만, 추가 배송·운영비는 150만 원이었습니다. 매출이 늘어도 이 실험의 순효과는 20만 원 손해입니다. 팀은 주문 수만 보고 확대하지 않고 최소 주문액을 바꾸거나 실험을 중단할지 비교합니다. 숫자는 이 가상 상황의 설정입니다.

생각해 볼 질문
사용이 늘수록 수익과 비용은 각각 어떻게 변합니까?

12. 업무 전체 흐름 — 한 부서의 개선이 다음 업무에도 도움이 되는지 본다

비즈니스 프로세스는 고객의 요청을 받은 때부터 최종 결과를 전달할 때까지 이어지는 업무 흐름입니다. 한 부서가 일을 빨리 넘겼다고 고객이 결과를 빨리 받는 것은 아닙니다.

접수팀이 신청을 많이 넘겼지만 서류가 빠져 심사팀이 계속 돌려보낸다면 고객은 더 기다릴 수 있습니다. 접수량만 보지 말고 보완 요청·심사·통보까지 따라가며 어디에서 오래 기다리는지 찾아야 합니다. 각 부서의 평가 기준도 전체 완료에 도움이 되는지 확인합니다.

가상 업무 예시

접수팀이 많은 신청을 넘겨 실적을 높여도 필수 자료가 빠져 심사팀이 계속 되돌려 보내면 전체가 느려집니다. 접수 건수와 최종 처리 완료를 함께 확인합니다.

생각해 볼 질문
접수팀의 처리 건수가 늘면서 심사팀의 자료 보완 요청도 늘지는 않았나요? 고객이 최종 결과를 받는 시간은 줄었나요?

13. 자동화 적합성 — 규칙과 예외부터 정리한다

비즈니스 규칙은 누가 언제 어떤 조건에서 일을 처리할지 정한 기준입니다. 자동화는 그 규칙을 프로그램이 실행하게 하므로 기준이 모호하면 잘못된 처리를 빠르게 반복할 수 있습니다.

담당자마다 고객 할인율을 다르게 기억한다면 먼저 할인 조건을 합의해야 합니다. 조건에 맞는 주문은 자동 계산하고 조건 밖의 요청은 지정된 사람이 판단하게 할 수 있습니다. 정상적으로 처리할 경우와 사람에게 넘길 예외를 나누는 것이 자동화 준비입니다.

가상 업무 예시

담당자마다 거래처 할인을 기억해서 처리하면 같은 거래처에 다른 할인율을 적용할 수 있습니다. 팀은 할인 조건과 예외 승인자를 먼저 정합니다. 조건에 맞는 주문은 자동 계산하고, 조건 밖의 요청은 지정한 승인자에게 보냅니다.

생각해 볼 질문
자동화할 규칙과 사람이 판단할 예외가 구분되어 있습니까?

14. 도입 방식 — 직접 만들기와 구매를 비교한다

IT 시스템은 직접 개발할 수도 있고 이미 만들어진 제품을 도입할 수도 있습니다. 직접 만들면 업무에 맞게 설계할 수 있지만 개발·시험·유지관리 인력이 필요합니다. 기존 제품은 빨리 시작할 수 있어도 원하는 기능이나 수정 범위가 제한될 수 있습니다.

예를 들어 휴가 신청에는 기존 제품이 충분할 수 있지만 특별한 승인 규칙이 있다면 실제로 지원하는지 시험해야 합니다. 시작 가격뿐 아니라 자료를 옮기고 다른 시스템과 연결하고 운영하는 비용까지 같은 기준으로 비교합니다.

가상 업무 예시

휴가 신청 시스템을 고르는 회사가 기존 제품으로 교대근무자의 반일 휴가를 처리해 봅니다. 신청·대리 승인·잔여 일수 계산은 되지만 야간 근무자의 날짜 계산은 맞지 않습니다. 회사는 제품 설정으로 해결할 수 있는지, 별도 연결 개발이 필요한지 확인하고 직접 개발안과 3년 비용·운영 인력을 비교합니다. 제품이 있다는 이유만으로 맞는 것도, 특수 규칙 하나 때문에 전부 직접 만들 필요가 있는 것도 아닙니다.

생각해 볼 질문
기존 제품이 우리 업무의 필수 조건을 지원하나요? 직접 개발하는 경우와 도입 기간·전체 비용·수정 가능 범위를 비교했나요?

15. 외주 협력 — 맡긴 뒤에도 확인 책임을 갖는다

IT 아웃소싱은 개발이나 운영의 일부를 외부 전문 업체에 맡기는 것입니다. 일을 맡겨도 우리 업무에 맞는지 결정하고 결과를 확인할 책임까지 없어지는 것은 아닙니다.

개발 경험이 많은 업체도 우리 회사의 반품 규칙을 처음부터 알지는 못합니다. 내부 담당자가 정상 반품과 예외 사례를 설명하고 중간 결과로 확인해야 합니다. 처음 요구한 내용이 바뀌면 일정·비용·인수 기준에 어떤 영향이 있는지도 함께 조정합니다.

가상 업무 예시

온라인 가구 업체가 반품 기능을 외주로 맡겼습니다. 업체는 반품 접수 즉시 전액 환불하도록 만들었지만, 발주사는 수거 후 훼손 여부를 확인해야 했습니다. 내부 업무 담당자가 ‘수거 전·수거 후·부분 훼손’ 사례로 중간 결과를 확인하고 환불 시점과 승인자를 합의합니다. 외주 개발사의 구현 능력이 발주사의 업무 판단을 대신하지는 않습니다.

생각해 볼 질문
계약 이후에도 업무 적합성과 진행 위험을 확인할 내부 담당자가 있습니까?

16. ERP와 정보 통합 — 부서 간 데이터의 뜻과 관리 담당자를 맞춘다

ERP는 구매·생산·판매·회계 등 여러 부서의 업무와 데이터를 통합해 기업의 자원을 관리하는 시스템입니다. 같은 주문을 부서마다 다시 입력하지 않고 이어서 사용할 수 있게 하는 것이 한 예입니다.

프로그램만 연결하면 데이터의 뜻까지 같아지는 것은 아닙니다. 판매팀의 ‘완료’는 결제 완료인데 배송팀의 ‘완료’는 배송 완료일 수 있습니다. 같은 상품의 코드와 상태의 뜻을 맞추고, 서로 다른 값이 있을 때 어느 기록을 기준으로 누가 수정할지 정해야 합니다.

가상 업무 예시

영업팀이 확정한 주문을 생산팀과 구매팀이 각자 다시 입력해 수량이 달라졌습니다. 회사는 주문 번호와 상품 코드를 공통으로 쓰고, 같은 주문에서 생산 필요량과 자재 구매량을 계산하도록 연결합니다. 반품과 취소 때 어느 부서가 상태를 바꾸는지도 정합니다. ERP를 설치하는 일과 부서가 같은 데이터를 기준으로 일하는 일은 함께 진행돼야 합니다.

생각해 볼 질문
부서마다 고객 주소가 다르면 어느 기록을 최신 정보로 사용하나요? 주소를 수정하고 다른 부서에 전달할 담당자는 누구인가요?

17. ITSM — 지속적인 서비스 운영을 준비한다

ITSM은 사용자가 필요한 IT 서비스를 계속 이용할 수 있도록 운영하고 품질을 관리하는 활동입니다. 계정 발급·문의·장애 처리처럼 공개 이후에도 해야 할 일이 포함됩니다. SLA는 제공자와 이용자가 지원 범위와 처리 시간 등 서비스 수준을 합의한 약속입니다.

직원이 계정을 어디에 신청할지 몰라 여러 부서에 연락한다면 프로그램이 있어도 이용하기 어렵습니다. 신청 경로·처리 담당자·현재 상태를 안내하고 실제로 약속한 지원이 이뤄지는지 확인합니다. 이를 맡을 인력과 비용도 도입 때 준비해야 합니다.

가상 업무 예시

신입 직원은 첫 출근일에 계정이 없어 일을 못 했고, 인사팀은 신청 메일을 보냈으니 처리됐다고 생각했습니다. IT팀은 신청 창구, 필수 정보, 발급 담당자와 완료 안내를 정하고 입사일까지 발급됐는지 확인합니다. 지연이 반복되면 승인 대기나 인력 부족을 조사합니다. 계정 기능이 존재하는 것과 필요할 때 사용할 수 있게 운영하는 것은 다릅니다.

생각해 볼 질문
사용자가 서비스 이용과 문제 해결을 어디에서 시작해야 하는지 압니까?

18. 지표의 부작용 — 평가 점수만 높이려는 행동을 살핀다

평가에 쓰는 지표는 사람의 행동에도 영향을 줍니다. 상담 시간이 짧을수록 좋은 점수를 주면 상담원이 문제를 해결하기 전에 통화를 끝내려 할 수 있습니다. 숫자는 좋아져도 고객의 문제는 남는 상황입니다.

따라서 지표가 원래 목표를 제대로 보여 주는지 살펴야 합니다. 상담 시간과 함께 해결 여부와 재문의도 확인하면 빨라진 것이 실제 개선인지 판단하기 쉽습니다. 점수를 높이는 행동과 고객에게 도움이 되는 행동이 어긋나면 평가 기준을 조정합니다.

가상 업무 예시

상담 시간만 줄이라고 하면 어려운 문의를 빨리 종료할 수 있습니다. 재문의와 해결 여부를 함께 확인해 실제 고객 문제가 줄었는지 판단합니다.

생각해 볼 질문
상담 시간이 짧을수록 높은 평가를 받는다면, 상담원이 문제를 해결하기 전에 통화를 끝낼 가능성은 없나요?

19. 작은 실험 — 전체 도입 전에 기대 효과를 시험한다

시범 운영은 새 방식을 전체에 적용하기 전에 작은 범위에서 실제로 써 보는 것입니다. 잘 작동하는지뿐 아니라 기대한 효과가 나고 다른 부담이 생기지 않는지도 확인합니다.

전 매장에 무인 주문기를 놓기 전에 한 매장에서 시험한다면, 주문 시간과 직원에게 도움을 요청한 횟수를 함께 볼 수 있습니다. 무엇이 어느 정도 좋아져야 확대할지와 어떤 문제가 생기면 중단할지를 미리 정해야 결과를 보고 다음 선택을 할 수 있습니다.

가상 업무 예시

점심 대기가 긴 식당이 무인 주문기를 한 매장에 설치해 봅니다. 주문은 빨라졌지만 처음 쓰는 고객을 돕느라 직원이 식탁 정리를 못 했습니다. 팀은 주문 시간과 도움 요청, 식탁 회전까지 함께 보고 안내 방식을 고칩니다. 시범 매장과 고객층·혼잡도가 다른 매장에는 같은 효과를 가정하지 않고 추가 확인 후 확대합니다.

생각해 볼 질문
전 매장 도입 전에 무엇을 확인해야 하나요? 한 매장에서 처리 시간과 직원의 도움 요청 건수를 비교해 볼 수 있나요?

20. 철수와 전환 — 서비스 종료와 자료 이전 비용을 준비한다

서비스 전환은 기존 서비스를 다른 서비스로 바꾸는 것이고, 종료는 사용을 끝내는 것입니다. 도입할 때부터 필요한 자료를 꺼낼 수 있는지와 다음 담당자가 일을 이어 갈 수 있는지 확인해야 합니다.

사용료가 올라 다른 제품으로 옮기려는데 고객 자료를 읽을 수 있는 형식으로 내보낼 수 없다면 이전이 어렵습니다. 자료를 꺼내고 새 시스템에 넣는 절차와 계약 종료 조건을 확인합니다. 이미 쓴 돈만 바라보지 말고 앞으로 계속 쓸 때와 바꿀 때의 비용·효과를 비교합니다.

가상 업무 예시

외부 서비스의 비용이 늘어 대체하려는데 자료를 표준 형식으로 내보낼 수 없다면 이전이 어려워집니다. 도입 전에 반출과 종료 절차를 시험합니다.

생각해 볼 질문
외부 서비스 사용을 끝낼 때 필요한 자료를 꺼낼 수 있나요? 자료 이전과 업무 인계를 누가 어떤 순서로 진행하나요?

교재에서 함께 확인할 내용

위 20개 노트는 교재 개념을 업무에 적용하는 길잡이입니다. 다음 이론과 기법은 별도로 읽고 직접 설명하거나 계산해 보세요. 이 목록도 교재 전체를 대신하지는 않습니다.

1. SWOT 분석

SWOT은 조직 안의 강점·약점과 조직 밖의 기회·위협을 나눠 살피는 방법입니다. 분석 인력이 없는 것은 내부 약점, 경쟁사의 가격 인하는 외부 위협이 될 수 있습니다. 네 칸을 채운 뒤에는 그 조건을 보고 어떤 사업을 하거나 미룰지 선택까지 설명해야 합니다.

확인해 보기: 자체 데이터 분석 인력 부족과 경쟁사의 가격 인하는 각각 어느 요소인가요?

IT 비즈니스와 윤리 · 38쪽 →

2. ERP와 업무 통합

ERP는 구매·재고·판매·회계 같은 회사의 주요 업무 정보를 함께 관리하는 시스템입니다. 영업에서 주문을 취소했는데 창고가 계속 출고하면 시스템을 도입해도 문제가 남습니다. 두 부서가 같은 주문 번호와 취소 상태를 공유하고 처리 순서도 맞춰야 합니다.

확인해 보기: 영업팀이 주문을 취소했는데 창고의 출고 목록에 반영되지 않으면 어떤 문제가 생길까요? 두 부서가 함께 확인해야 할 정보는 무엇인가요?

IT 비즈니스와 윤리 · 83쪽 →

3. SLA와 서비스 수준 관리

SLA는 서비스가 어느 수준으로 제공돼야 하는지 당사자가 합의한 약속입니다. 예를 들어 장애 접수 가능 시간과 복구 목표, 측정 방법을 정합니다. 서비스 수준 관리는 실제 측정 결과가 약속에 맞는지 확인하고 미달 원인을 고치는 활동입니다.

확인해 보기: 가용성 목표를 약속할 때 측정 기간과 제외 시간을 함께 정해야 하는 이유는 무엇인가요?

IT 비즈니스와 윤리 · 102쪽 →

4. BSC의 네 관점

BSC는 성과를 재무·고객·내부 업무·학습과 성장의 네 관점으로 살피는 방법입니다. 매출만 보지 않고 고객 재구매, 주문 처리 시간, 직원의 역량도 확인합니다. 당장의 금전 성과와 앞으로 그 성과를 만드는 조건을 함께 보려는 것입니다.

확인해 보기: 고객 재구매율, 처리 시간, 직원 역량 향상은 각각 어떤 관점과 연결되나요?

IT 비즈니스와 윤리 · 109쪽 →