Proof of Value: Teva가 공장 30곳에 넣을 AI를 다섯 질문으로 고르는 법

Teva는 "기술이 작동하나"를 묻는 PoC 대신 "우리 공장에서 가치를 내고 규제 아래 굴러가고 현장이 믿고 움직이나"를 묻는 Proof of Value로 AI를 고릅니다. 따라 하려면 현장 문제 목록, 사이트별 데이터 준비도 점검, 결정 흐름과 추적 요건을 POV 설계 첫날에 넣는 채점표가 필요합니다.

요약

IIoT World의 Paul Viorel은 Industrial AI Summit 2026 패널에서 Teva Pharmaceuticals의 Maya Schushan-Orgad가 소개한 Teva Rise 프로그램을 정리했습니다. Teva Rise는 Teva가 30개 공장 네트워크에 외부 기술을 들여오려고 만든 오픈 이노베이션(사외 기술을 공개 모집해 들여오는 방식) 플랫폼입니다. 시작점은 기술이 아니라 현장 문제였습니다. 운영 전문가들이 먼저 가장 큰 pain point(현장의 고질적 문제)를 꼽았고 품질 위험 조기 예측, 설비 신뢰성, 더 나은 공급망 의사결정이 목록에 올랐습니다. 이 주제로 제조 품질과 공급망 AI 챌린지를 열었고 1년 동안 기술 약 300개를 평가했습니다.

문제 정의 → 공개 모집 → 가치 검증 → 공장 확산

평가 방식이 이 사례의 중심입니다. Teva는 PoC(proof of concept, 기술이 작동하는지 보는 시험) 대신 Proof of Value(POV, 우리 환경에서 가치를 내는지 보는 시험)를 씁니다. POV는 다섯 질문을 통과해야 하고 벤더와 함께 설계하며 결정 흐름 지도와 추적 요건을 처음부터 넣습니다. 데이터나 시스템이 준비되지 않은 사이트에서는 뛰어난 벤더라도 도입을 미룹니다. 이렇게까지 하는 이유는 원가 구조에 있습니다. 운영이 Teva 원가의 약 70%를 차지하므로, 제네릭 중심에서 바이오제약 회사로 옮겨 가는 전략 “Pivot to Growth”에서 공장 효율이 큰 몫을 합니다. 원문은 이 전략이 13분기 연속 성과를 냈다고 전합니다. 아래에서는 POV를 이루는 다섯 메커니즘과, 실제로 돌릴 때 필요한 채점표와 일정을 풉니다.

운영이 원가의 약 70%라서 공장 효율이 전환 전략의 무게중심이 됩니다

핵심 메커니즘

Pain-point-first Challenge: 기술 목록이 아니라 현장 문제 목록에서 출발하기

무엇인가. 외부 기술을 찾기 전에 현장 운영 전문가가 풀고 싶은 문제를 먼저 정하고 그 문제를 주제로 공개 챌린지를 여는 방식입니다.

어떻게 작동하나. 운영 전문가가 가장 아픈 문제를 꼽으면 그것이 챌린지 주제가 됩니다. 외부 벤더는 그 주제에 맞춰 기술을 제안하고 평가팀은 “이 기술이 어느 문제를 푸나”로 후보를 묶습니다. 출력은 문제별 후보 목록이며 여기서 POV 대상을 고릅니다. 기술 박람회에서 좋아 보이는 도구를 먼저 사고 쓸 곳을 찾는 순서를 뒤집은 셈입니다.

언제 쓰고 언제 안 쓰나. 공장이 여럿이고 외부 기술 제안이 많이 들어오는 회사에 맞습니다. 이미 풀어야 할 문제와 해법이 정해진 단일 과제라면 공개 모집보다 바로 벤더를 지정하는 편이 빠릅니다.

원문의 예. Teva는 품질 위험 조기 예측, 설비 신뢰성, 공급망 의사결정을 주제로 제조 품질·공급망 AI 챌린지를 열었습니다.

작은 예시(가상 예시). 어느 정제 공장 운영팀이 “코팅 공정 이탈을 배치 종료 뒤에야 안다”를 첫째 문제로 꼽습니다. 챌린지 공고에는 이 문제와 쓸 수 있는 데이터(공정 기록, 품질 시험 결과)만 적고 해법의 형태는 열어 둡니다.

기술 목록이 아니라 현장 문제 목록에서 출발합니다

Proof of Value: 다섯 질문을 모두 통과해야 하는 시험

무엇인가. 기술이 작동하는지에서 멈추지 않고 Teva의 공장과 규제 환경에서 측정 가능한 가치를 내는지까지 확인하는 평가입니다.

어떻게 작동하나. 다섯 질문으로 후보를 봅니다. 우리 환경에서 작동하나, 서로 다른 공장들로 이루어진 네트워크에 통합되고 확산되나, 과제에 답하며 가치를 숫자로 보여 주나, 고도 규제 환경에서 현실적으로 운영되나, 현장 사용자가 결과를 믿고 행동할 수 있나입니다. 원문은 마지막 질문을 “can users trust and act on the output”라고 적습니다. 이 과정에서 사이트에 데이터가 실제로 있는지, 작업자가 큰 변화 관리 없이 권고를 기존 업무에 끼워 넣을 수 있는지, 성능 지표가 사업 가치로 바뀌는지도 함께 시험합니다.

언제 쓰고 언제 안 쓰나. 기술 자체가 검증된 시장 제품이고 문제는 “우리 공장에서도 되나”인 경우에 맞습니다. 아직 세상에 없는 기술이라 작동 여부부터 모른다면 짧은 PoC가 먼저입니다.

원문의 예. 원문은 PoC와 POV를 핵심 질문(작동하나 / 우리 환경에서 작동하나), 시험 초점(데모 성능·단독 시험 / 통합·확산·가치·업무 적합), 준비도(기술 준비도 / 규제·신뢰 준비도)로 대비합니다.

PoC가 '작동하나'만 묻는다면 POV는 다섯 질문을 모두 통과해야 합니다

같은 시험이라도 묻는 질문과 준비도의 기준이 다릅니다

Site Readiness Gate: 벤더보다 사이트의 준비 상태를 먼저 보기

무엇인가. 사이트의 데이터 성숙도나 시스템 준비도가 모자라면, 아무리 좋은 벤더라도 그 사이트 도입을 미루는 규칙입니다.

어떻게 작동하나. 후보 기술이 정해지면 적용할 사이트부터 점검합니다. 필요한 데이터가 그 사이트에 있는지, 연결할 시스템이 준비됐는지를 봅니다. 준비됐으면 벤더와 POV를 설계하고 아니면 내부 환경이 갖춰질 때까지 보류합니다. 실패 원인을 벤더 탓으로 돌리기 쉬운 상황을 미리 걸러 내는 장치입니다.

언제 쓰고 언제 안 쓰나. 공장마다 설비 세대와 데이터 수준이 다른 네트워크에 필요합니다. 공장이 하나뿐이거나 모든 사이트가 같은 시스템을 쓰면 점검이 짧아집니다.

원문의 예. Teva는 데이터 성숙도나 시스템 준비도가 부족한 사이트에서 강한 벤더도 미루고 내부 환경 정비를 먼저 합니다.

벤더의 실력보다 사이트의 준비 상태가 먼저 진행 여부를 가릅니다

Decision Flow Mapping과 Traceability by Design: 추적 요건을 첫날 넣기

무엇인가. AI 결과가 어떤 데이터에서 나와 누가 보고 무엇을 결정했는지의 흐름(decision flow mapping)과, 그 흐름을 기록으로 남기는 추적 요건(traceability)을 POV 설계 단계에서 정하는 방식입니다.

어떻게 작동하나. 벤더와 POV를 설계할 때 입력 데이터, 모델 출력, 사람의 판단, 남길 기록을 한 줄로 그립니다. 배포한 뒤 규제 요건을 덧붙이지 않고 시험 첫날부터 이 기록이 쌓이게 만듭니다. 그래서 POV가 끝나면 “규제 아래에서도 굴러가나”에 대한 증거가 함께 남습니다.

언제 쓰고 언제 안 쓰나. 제약·식품·의료기기처럼 의사결정 기록이 감사 대상인 산업에서는 필수입니다. 규제가 약한 업종에서도 AI 권고를 사람이 승인하는 업무라면 쓸모가 있습니다.

원문의 예. 원문은 Teva가 POV를 벤더와 함께 설계하고 결정 흐름 지도와 추적 요건을 처음부터 넣는다고 전합니다.

POV 설계 단계에서 결정 흐름과 추적 요건을 먼저 그립니다(개념도)

Traceability as Operating Asset: 규제용 기록을 운영 데이터로 다시 쓰기

무엇인가. 규제 대응을 위해 남긴 데이터 이력을 예지 정비, 품질 관리, 운영 개선에 다시 쓰는 관점입니다.

어떻게 작동하나. 추적 기록에는 어떤 설비에서, 어떤 조건으로, 어떤 판단이 있었는지가 남습니다. 이 기록을 모으면 예지 정비 모델의 학습 데이터가 되고 품질 관리 시스템(QMS)의 이탈·조치 기록과 이어지며 반복 문제의 원인을 찾는 재료가 됩니다. 추적성이 비용 항목에서 데이터 자산으로 바뀝니다.

원문의 예. Teva는 추적성을 규제 준수 너머로 넓혀, 규제 기관을 만족시키는 데이터 이력을 예지 정비 모델, 품질 관리 시스템, 운영 개선에 씁니다.

규제를 위해 남긴 데이터 이력이 예지 정비, 품질 관리, 운영 개선의 재료가 됩니다

통념과 다른 주장

흔히 이렇게 봅니다PoC에서 기술이 작동하면 다음은 확산 예산을 잡는 일이다.

Teva는 이렇게 봅니다작동 여부는 시작일 뿐이고 우리 공장망·규제·현장 신뢰까지 다섯 질문을 통과해야 가치가 증명된다.

근거Teva Rise는 30개 공장망에 넣을 기술 약 300개를 1년 동안 이 POV 방식으로 평가했습니다.

흔히 이렇게 봅니다기술이 가장 뛰어난 벤더를 고르면 된다.

Teva는 이렇게 봅니다규제 요건, 설명 가능성, 추적성이 제품에 들어 있지 않으면 기술이 더 좋아도 쓸 수 없다.

근거평가 과정에서 제약 경험이 없는 벤더의 더 뛰어난 기술을 규제·신뢰 요건이 빠져 도입하지 못한 경우가 있었습니다.

흔히 이렇게 봅니다추적성과 감사 기록은 규제 때문에 치르는 비용이다.

Teva는 이렇게 봅니다규제를 위해 남긴 데이터 이력이 예지 정비와 품질 관리, 운영 개선의 재료가 된다.

근거Teva는 추적성을 규제 준수 너머로 넓혀 이 세 영역에 씁니다.

저자가 든 사례

Teva Rise: 1년간 기술 약 300개 평가

구분	내용
상황	30개 공장 네트워크, 운영이 원가의 약 70%, Pivot to Growth 전략으로 바이오제약 전환 중
한 일	현장 pain point로 품질·공급망 AI 챌린지를 열고, PoC 대신 다섯 질문짜리 POV로 평가
결과	1년간 기술 약 300개 평가. 절감액·가동률 같은 AI 성과 수치는 원문에서 밝히지 않음
연결	Pain-point-first Challenge, Proof of Value

성과 수치(절감액·가동률)는 원문에서 밝히지 않음

데이터가 준비되지 않은 사이트의 보류

구분	내용
상황	공장마다 데이터 성숙도와 시스템 준비도가 다름
한 일	준비가 모자란 사이트에서는 강한 벤더라도 도입을 미루고 내부 환경부터 정비
결과	보류한 사이트 수와 기간은 원문에서 밝히지 않음
연결	Site Readiness Gate

제약 경험 유무로 갈린 벤더

구분	내용
상황	약 300개 평가에서 제약 경험이 있는 벤더와 없는 벤더 사이에 뚜렷한 격차가 보임
한 일	규제 요건, 설명 가능성, 추적성이 처음부터 들어 있는지를 평가
결과	비제약 벤더의 더 뛰어난 기술 일부는 규제·신뢰 요건이 없어 도입하지 못함
연결	Decision Flow Mapping과 Traceability by Design

약 300개 평가에서 드러난 격차(원문의 관찰)

기술 디테일: 실제로 돌릴 때 필요한 것

Pain-point-first Challenge로 300개 안팎의 접수를 소화하려면 벤더 제출물을 LLM으로 먼저 구조화합니다. 소개서, 데모 기록, 보안·규제 문서를 넣고 아래 필드만 JSON으로 뽑게 합니다. 구조화 출력(JSON 스키마 강제)을 켜고 temperature는 0으로 둡니다. 같은 후보를 3회 채점해 질문별 점수 차이가 2점 이상 나면 사람이 다시 봅니다. 문서에 근거가 없는 필드는 null로 남기게 하고 추정으로 채우지 못하게 프롬프트에 적습니다. 필드 이름과 값은 모두 가상 예시입니다.

{
  "vendor": "ExampleVendor",
  "challenge": "quality-risk-early-warning",
  "pain_point_fit": "코팅 공정 이탈을 배치 중에 예측",
  "required_data": ["process_historian", "lims_results", "batch_record"],
  "integration": {"connectors": ["OPC UA", "REST"], "on_prem": true},
  "pharma_refs": 2,
  "audit_trail": true,
  "explainability": "예측마다 상위 기여 변수 표시",
  "value_metric": "배치 이탈 건수, 재작업 시간",
  "evidence_pages": ["deck p.7", "security doc p.3"]
}

가상 예시: 대량 접수를 구조화하고 사람은 판정에 집중합니다

Proof of Value 다섯 질문을 점수로 바꾸려면 질문마다 0·3·5점 기준을 미리 적습니다. 다섯 점수를 더해 순위를 매기되, 0점이 하나라도 있으면 합계와 상관없이 확산하지 않습니다. Q4(규제 운영)와 Q5(신뢰·행동)는 제약처럼 규제가 강한 산업에서 가중치를 1.5배로 둘 수 있습니다. 아래 기준은 가상 예시입니다.

가상 예시: 질문마다 0점이 하나라도 있으면 확산하지 않습니다

Site Readiness Gate를 자동 점검하려면 사이트마다 같은 쿼리를 돌립니다. 최근 12개월 공정 기록(historian)에서 대상 설비 태그가 비어 있는 비율, 배치 번호로 공정 기록·품질 시험 결과(LIMS)·배치 기록을 이을 수 있는 비율, 타임스탬프 시간대가 맞는지를 봅니다. 예를 들어 태그 결측 10% 이하, 배치 연결률 95% 이상을 준비됨으로 둡니다. 기준에 못 미치면 벤더 일정보다 데이터 정비 작업을 먼저 잡습니다. 수치는 예시이며 회사 기준으로 바꿉니다.

Decision Flow Mapping을 기록으로 남기려면 AI 권고 한 건마다 아래 이벤트를 씁니다. 핵심은 모델 출력과 사람의 조치를 같은 레코드에 묶는 것입니다. 누가 보고 받아들였는지 무시했는지, 그 이유가 무엇인지가 남아야 Q5(신뢰·행동)를 측정할 수 있습니다. 필드는 가상 예시입니다.

{
  "decision_id": "SITE07-COAT-20261105-0142",
  "site": "SITE07",
  "batch_id": "B26-1105-03",
  "model_version": "risk-coat-1.4.2",
  "input_refs": ["historian:coater2/2026-11-05T02:00..04:00"],
  "output": {"risk": 0.81, "top_factors": ["inlet_temp", "spray_rate"]},
  "recommendation": "스프레이 속도 점검",
  "user": "operator_312",
  "action": "accepted",
  "reason": null,
  "signed_at": "2026-11-05T04:12:09+09:00"
}

POV 기간에는 action이 accepted인 비율과, 무시했을 때 남긴 reason을 매주 봅니다. 수락률이 낮고 이유가 “근거를 모르겠다”에 몰리면 설명 표시 방식을 고칩니다.

Traceability as Operating Asset으로 재사용하려면 위 이벤트 테이블을 설비 ID와 배치 ID로 정비 이력, QMS 이탈 기록과 잇습니다. 그러면 “AI가 경고했고 사람이 조치했는데도 이탈이 난 배치”를 따로 뽑아 예지 정비 모델의 학습 데이터와 원인 분석 목록으로 쓸 수 있습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	맡는 일
오픈 이노베이션·AX 추진 리더	챌린지 공고, 벤더 접수, 1차 선별 운영, 확산 판정 회의 주관
사이트 운영 전문가	pain point 정의, 가치 지표 확정, POV 중 현장 피드백
품질보증·규제 담당	추적 요건 정의, Q4 채점, 밸리데이션 범위 판단
사이트 IT·OT·데이터 담당	Site Readiness 점검, 데이터 연결, 결정 기록 저장
라인 작업자·감독자	권고 수락·거절과 이유 기록, Q5 인터뷰 응답
벤더	POV 공동 설계, 설명 가능성·감사 기록 기능 시연

준비물. 사이트별 pain point 상위 3개와 그 문제의 현재 비용(재작업 시간, 이탈 건수, 정비 비용), 사이트별 데이터 목록(공정 기록, 품질 시험, 배치 기록, 정비 이력), 사이트 간 시스템 차이 표, 회사의 컴퓨터 시스템 밸리데이션 절차, 벤더 평가 채점표가 필요합니다.

가상 예시: 문제 정의부터 확산 판정까지 약 20주

기간	할 일	산출물
1~2주	사이트 운영 전문가 인터뷰, pain point와 가치 지표 확정	챌린지 주제 목록, 기준선 값
3~6주	챌린지 공고, 접수, LLM 구조화와 1차 채점	후보 상위 목록
7~8주	Site Readiness 점검, 벤더와 POV 공동 설계, 결정 흐름 지도 작성	POV 계획서, 결정 흐름 지도
9~20주	준비된 사이트에서 POV 실행, 주간 수락률·가치 지표 점검	다섯 질문 채점표, 확산·보류 판정

일정은 가상 예시이며 규제 밸리데이션 범위에 따라 늘어납니다.

현업에 물을 것.

이 문제가 지금 한 해에 얼마의 비용(시간·재작업·폐기)을 만들고 있나요?
이 문제를 판단할 데이터가 이 사이트에 지금 있고 배치 번호로 서로 이어지나요?
AI 권고가 나오면 누가 보고 몇 분 안에, 어떤 조치를 하나요?
이 결정 기록을 감사에서 보여 줘야 하나요? 그렇다면 무엇이 남아야 하나요?
같은 문제를 가진 다른 사이트는 몇 곳이고 시스템은 같나요?

진행 판정 기준(예시). 다섯 질문 모두 3점 이상이고 합계가 20점 이상이면 두 번째 사이트로 넓힙니다. 하나라도 0점이면 중단하거나, 원인이 사이트 준비도라면 보류로 기록하고 정비 뒤 다시 엽니다. POV 기간 권고 수락률이 60% 미만이면 Q5를 3점 이하로 둡니다. 가치 지표는 기준선 대비 개선 폭을 원가로 환산해 보고합니다. 수치는 모두 예시입니다.

AX 적용 제언. 공장이 여러 곳이고 규제나 고객 감사가 엄격한 제약, 식품, 화학, 반도체 소재 제조사에 바로 옮길 수 있는 틀입니다. 첫 단계는 벤더 찾기가 아니라 사이트 운영 전문가에게서 pain point와 그 비용을 받는 일입니다. 다음으로 Site Readiness 점검을 벤더 선정과 따로 돌려, 데이터 정비가 필요한 사이트를 일찍 가려냅니다. 벤더 계약서에는 감사 기록, 예측 근거 표시, 모델 버전 기록을 기본 요건으로 넣습니다. 진짜 성과 지표는 POV 한 건의 정확도가 아니라, 같은 기술을 두 번째와 세 번째 사이트에 얼마나 빨리 옮겼는지입니다.

원문 사례

항목	내용
기사	IIoT World, Paul Viorel, 2026.11.04 게재
발표 자리	Industrial AI Summit 2026 패널. 사회 Rick Franzosa(Tech-Clarity), 패널 Maya Schushan-Orgad(Teva), Adam Procopio(Merck), Kristen Sauter(Adlib Software)
프로그램	Teva Rise, 제조 AI를 고르고 시험하고 확산하는 오픈 이노베이션 플랫폼
규모	30개 공장 네트워크, 1년간 기술 약 300개 평가
챌린지 주제	품질 위험 조기 예측, 설비 신뢰성, 공급망 의사결정
평가 방식	PoC 대신 다섯 질문짜리 POV, 벤더와 공동 설계, 결정 흐름 지도·추적 요건을 처음부터 반영
보류 규칙	데이터 성숙도·시스템 준비도가 부족한 사이트는 강한 벤더라도 보류
벤더 관찰	제약 경험 있는 벤더는 규제·설명 가능성·추적성을 내장, 비제약 벤더 일부는 기술이 더 좋아도 도입 불가
경영 맥락	운영이 원가의 약 70%, Pivot to Growth 전략 13분기 연속 성과

핵심 개념

Teva Rise: Teva가 규제를 받는 제약 공장망에 넣을 AI를 고르고 시험하고 확산하는 오픈 이노베이션 프로그램입니다.
open innovation: 회사 밖의 기술과 아이디어를 공개 모집해 내부 문제 해결에 쓰는 방식입니다.
Pivot to Growth: 제네릭 중심에서 바이오제약 회사로 옮겨 가는 Teva의 전략 이름입니다.
heterogeneous factory network: 설비 세대, 시스템, 데이터 수준이 서로 다른 공장들로 이루어진 생산망입니다.
change management: 새 도구를 쓰도록 사람의 일하는 방식과 역할을 바꾸는 활동. Teva는 큰 변화 관리 없이 기존 업무에 들어가는지를 봅니다.
explainability: AI가 왜 그런 결과를 냈는지 사람이 확인할 수 있게 보여 주는 성질입니다.

내 메모

TODO: 내 생각 추가

원문은 IIoT World에 실린 Paul Viorel의 「How Teva Selects AI for 30 Factories」(2026.11.04 게재)이며 Industrial AI Summit 2026 패널에서 Teva의 Maya Schushan-Orgad가 소개한 내용을 정리한 기사입니다. 원문은 후보 주소(iiot-world.com)에서 그대로 읽었습니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 기술 디테일, 현업 실행 디테일, JSON 예시, 채점 기준표, 일정표, 판정 기준, 인포그래픽은 실제로 돌릴 때 필요한 내용을 새로 작성했으며 가상 예시는 그렇게 밝혔습니다. 원문은 Schushan-Orgad의 직함, 평가한 벤더 이름, AI 도입 성과 수치를 밝히지 않았습니다. 전체 내용은 원문에서 볼 수 있습니다.