(설치및 활용QnA게시판에서 이동했습니다.)요양원에서 환자 관리 프로그램을 개발하려고합니다. 이게 가능한지 문의 드립니다.

half4u의 이미지

회사(요양원)가 IT쪽과는 한참 먼지라 어처구니없는 내용이 있더라도 가르침을 바랍니다.

현재 3곳에 요양원이 있고 각각 100여분의 어르신들이 입소해 계십니다.
그런데 각 어르신별 파일을 수작업으로 차트를 만들어 관리하다보니 각각 파일들이 부분적으로 업데이트가 돼는등 점점 문제가 커지고 있습니다.ㅜ.ㅜ
내용은 어르신별 신상파일과 각 어르신별 제공돼는 식사, 투약, 비용정산, 수발서비스(세수,양치,기저귀등등) 종류, 기타 특이사항입니다.
병원 OCS에 비해 검사및 수술 관련사항이 없고 내용이 어느정도 정형화돼어 있어서
병원 OCS는 개발비가 보통 수십억에서 수억정도 비용이 들어가지만 국내에서 요양원을 대상으로한 프로그램은 초기비용이 수천여만원에 매달 200여만원이 들어간다고 합니다.

그러나 내용자체가 현실에 맞지않는부분들이 많고 이를 고친다해도 과연 얼마나 반영해줄지 모르기때문에 자체계발을 추진중입니다.

최소 요구조건은 각 어르신별 정보를 레코드로 만들어서 각 직역의 전문가인 사회복지사, 영양사, 간호사, 요양보호사(간병전문가)가 자기 전문분야 필드를 각각 하루 1회에서 수회정도 업데이트하는데 자신이 입력,수정할 수 있는 정보가 아니면 검색만 가능하고 수정할 수 없어야합니다.
그외 구현사항은 액세스로 구현이 가능함을 확인했습니다.

이왕 추진하는김에 위시스템을 오픈소스 프로그램으로 구현하고십습니다.
그레서 다음과 같은 계획을 세웠습니다.

1. 그렇다면 리눅스서버에서 '오픈 오피스'의 '베이스'로 위 데이터 베이스를 만들고 각 전문가별로 아이디를 부여해 각 아이디별 테이블 파일을 해당 유저만 수정할수 있고 다른 유저들은 볼수만 있는 형태로 구현합니다

2. 서버 컴퓨터 1대에 1번과같은 시스템을 구현하고 직원별로 리눅스 라이브CD를 만들어서 배포하고자합니다.
CD부팅을 한경우에 자동으로 실행되는 스크립트를 이용해서 위 1번에서 구축한 서버에 자동으로 접속하여 해당 '베이스'프로그램이 실행돼도록합니다.

그레서 최종적인 질문입니다.(참 길게도 설명했습니다...ㅜ.ㅡ)

결론>>
1. 위 계획이 실현가능할까요?
2. 라이센스 문제는 없을까요?
3. 게시판 검색하다보면 LAMP라고해서 리눅스, 아파치, MySQL, PHP로 구현한다고하는데 위 시스템을 구축하는데도 이걸 모두 사용해야하는것인가요?ㅡ.ㅡ
4. 프리랜서 리눅스 계발자분들을 고용하여 시스템 계발이 완성된후 고용됐던 계발자가 다른 인력으로 교체된다해도 지속적인 버그수정이나 개선사항반영을 할 수 있도록 계발과정및결과물을 관리 할 수 있는 방법이 있는지요?

p.s 허접한 질문입니다만 컴퓨터를 전혀 모르는 직원들을 대상으로 리눅스를 활용한 프로젝트를 추진하려는 1인에게 우문현답으로 도움
부탁드립니다.-.- _ _ -.-

익명 사용자의 이미지

웹개발..하면 될 것 같은데요.
리눅스는 중요치 않고, 저라면 자바스크립트+JSP(톰캣)+MYSQL 로 하겠습니다.
적당히 문서화 잘 하시고 기본만 할 줄 아는 분이 계시면 구축하고 쓰는데 지장없을 듯 합니다..
돌아가게만 하는 거면 대학생 수준으로도 가능하지만 '잘' 돌아가는 건 좀 다른 문제지만요.

익명 사용자의 이미지

추천 ^^

snowall의 이미지

웹 개발하시면 될듯 싶은데요.

웹서버 한대 구축해서 MySQL로 DB돌리고 아파치로 웹서버 돌리면 됩니다. MySQL이나 아파치는 윈도우용도 있으니까 윈도에서 쓰셔도 상관 없습니다. 근데 윈도우즈 서버 버전은 비싸요...

개발 언어는 PHP도 좋고 JSP도 좋고 파이썬도 좋겠죠. 다만, 하나를 쓰기 시작하면 그 언어만 계속 써야 하니까 앞으로 유지보수를 할 개발자 수급은 고려하시는게 좋습니다.

다른건 크게 어렵지 않을 것 같고, 백업과 장애복구 정책에 신경쓰시는게 좋겠죠. 어딘가에 미러링을 한다거나, 일단위로 백업을 해둔다거나...

웹으로 하시면 좋은점이, 직원들이 실제로 사용하는 운영체제에 상관없이 적용 가능하다는 점입니다. 웹표준에 맞게 개발한다면 심지어 스마트폰에서도 일을 처리할 수 있죠.

피할 수 있을때 즐겨라! http://melotopia.net/b

half4u의 이미지

업무때문에 질문올리고 찾아보는중인데 개인적으로 빠져드는 느낌이 들고 있답니다.^^
그런데 왠지 불안한 기분도...ㅡ.ㅡ; 다량의 시간과 자원을 뺏길지도...

익명 사용자의 이미지

  1. 위 계획이 실현가능할까요?
  • 오픈 오피스 층이 힘듭니다. 유지보수 아예 안된다고 보시면 됩니다. 왜냐면 이쪽 인력을 구하는건 거의 불가능합니다.
  1. 라이센스 문제는 없을까요?
  • 문제 없다고 생각합니다.
  1. 게시판 검색하다보면 LAMP라고해서 리눅스, 아파치, MySQL, PHP로 구현한다고하는데 위 시스템을 구축하는데도 이걸 모두 사용해야하는것인가요?ㅡ.ㅡ
  • 예, 언어는 상관없다고 봅니다만, PHP가 사람 구하기 그나마 가장 쉬울겁니다.
  1. 프리랜서 리눅스 계발자분들을 고용하여 시스템 계발이 완성된후 고용됐던 계발자가 다른 인력으로 교체된다해도 지속적인 버그수정이나 개선사항반영을 할 수 있도록 계발과정및결과물을 관리 할 수 있는 방법이 있는지요?
  • 순전히 개발자에 달려 있으며, 처음에 이를 이끌기 위해서는 고수 개발자를 고용하거나, 최소한 고수 개발자가 조언해 줄수 있는 환경이 필요합니다. IT 개발 과정이나 프로젝트가 생소한분 같은데, 성공적으로 이끈는건 거의 불가능합니다. 물론 미국 사례 중 성공 사례도 얼마든지 있어서, 완전히 불가능하다는건 말씀드리지 못하겠습니다. 컨설팅에 관해서는 재능 기부 형태나 댓가 지불 방법을 찾으셔야할 것 같습니다.

라이브 CD 배포는 무의미하다고 생각합니다. 엑셀 계층을 빼버리고 그냥 웹사이트 구축후, 사이트 주소를 뿌리는게 좋습니다. 모든 컴에 웹 브라우저는 있을테니까요.

익명 사용자의 이미지

위에 덧붙이자면(위 익명과 다른 익명임)
* 오픈오피스 Base는 충분히 테스트해보고 사용하셔야 됩니다.(비추천)
* DB 설계만 제대로 해 놓으면 PHP를 쓰든, Java를 쓰든 상관이 없습니다.
DB 설계를 제대로 해놓고 그 시대에 구하기 쉬은 인력을 구하시면 됩니다.

익명 사용자의 이미지

원래 익명입니다.

이분의 DB설계 말씀은 프로그래머 기준입니다. (전 이 의견에 30~40% 정도는 동의 합니다. 반대는 안한다는 겁니다.)

원 글을 작성하신 half4u 님께서는 기획의 입장이므로 전체 제품의 문서화된 명확한 기획이 있는게, 할수 있는 최선책입니다. 더 나아가면 페이퍼 프로토타이핑 정도나, 그림 자료와 거기에 주석이 있으면 가장 좋습니다.

half4u의 이미지

다른 도움주시는분들도 많지만(KLDP에 고마운건가...^^;;) 님의 도움도컸습니다.

그레서......

아래와같이 진행중입니다.

개인공부.
'성공적인 웹 프로그래밍 PHP와 MySQL <제3판> /정보문화사'를 보면서 --> AMP공부
'웹 개발자를 위한 웹을 지탱하는 기술/멘토르'---> HTTP,URI,HTML 배경 공부
'객체지향적으로 생각하라 !/정보문화사'--->PHP의 OO부분 이해를 위해 ㅠ.ㅜ
'대한민국 개발자 희망보고서/한빛미디어'--->추후 개발자 외주 작업에 대비해 분위기 파악용

회사조치.
1.각직역별 요구사항 정리를 위한 업무개편.
(컴퓨터에 비교적 익숙한 중앙 조직을 업무지원실로 통폐합하고 미숙련 각사업장 직역팀장을 실무현업에서 업무보조역으로
전환. 10월부터 ****팀장 전산화 요구사항 정리 전담예정)
2.유사시 기존 문서포맷의 이전을 용이하게 하기위해 한글은 97, MS-office는 2003으로 통일토록지시.
(상위 버전필요시 문서화하여 보고할것)

왠지 배가 산으로 가는것 같지만....ㅡㅡ+
전혀 모를때와 위서적들도 보고 KLDP 게시판을 확인해가면서 '아는것'과 '이해'하는것의 차이가 크다는점도 알게됩니다.
위자료말고도 5권을더 쌓아놓고있는데 이걸 언제다 보나....보다도 시간이 왜 이리 빨리가나, 연휴가 벌써 하루밖에 않남아서 안타깝네요..

어쨌든 올해내에 프로토타입및 가시연을통한 요구사항 완벽정리를 향해 열심히 뛰겠습니다..^^

익명 사용자의 이미지

원래 익명입니다.

열정적인 노력 정말 대단하십니다.

특히 이 말씀에 대해서 환영합니다.

'어쨌든 올해내에 프로토타입및 가시연을통한 요구사항 완벽정리를 향해 열심히 뛰겠습니다..^^'

자칫 제가 선택한 몇가지 단어가 오해를 불러일으킬 수 있을 것 같아서 첨언합니다. 제가 강조하고 싶은 '명확한 전체 기획'은 '모든 요구사항을 포함한' 의미가 아닙니다.

예를들어 half4u 님께서 말씀하신 프로젝트의 요구사항은 조금만 더 세세하게 들어가면 그 양이 많아 집니다. 위의 스펙에 두가지 시나리오만 넣어 보겠습니다.

A환자가 2008년~2010년 사이에는 집에서 요양하였다.

A환자의 담당자 B씨는 2010년에 퇴직하고 C가 이어 받는다.

이렇게 두가지 시나리오가 추가되고 조회하려고 치면, 인사 관리 시스템이 어느 정도 들어가 버리게됩니다. 얼마든지 큰 시스템이 될수 있습니다.

그래서 모든 요구 사항을 수집하시면, 너무 많은 요구 사항속에서 끝없는 개발이 될수도 있습니다. 그래서 초반의 목표는 최소로 잡고 그 '전체의 모습을 명확하게 기획' 하세요.

특히 가장 사람들이 원하는 것만 충족 시키는 최소 제품을 만들고 거기에서 거기서부터 1~3개월 마다 주기를 정하고 기능을 오픈하면서 점진적인 개발을 추천합니다.

프로젝트를 시작해보시면 아시겠지만, 개발 주기를 관리해서 사람들이 지치지 않고 지속적으로 개발할 수 있는 환경을 만들어 나가는 것도 중요합니다.

일단 가장 유명한 사례 하나에 기대봅니다. 물론 규모나 분야가 맞지 않을수 있지만, 이 사례는 FBI가 자신들의 종이나 오프라인으로 하던 프로세스를 전산으로 바꾸는 과정입니다. 그래서 본질적으로 half4u 님의 목표와 비슷하다고 느낍니다.

FBI 센티널, 최악의 프로젝트에서 공공IT '귀감' 된 사연 - 비즈니스 혁신의 동반자 CIO BIZ+

위 프로젝트는 2001년에 시작되서 거의 7~8년 동안 5억 달러를 낭비하다가, 2008년에 담당자가 개발 방법을 바꾸면서 2년만에 프로젝트의 모범이 되었습니다.

위 사례를 자세히 보면, 많은 기능 구현 후 한꺼번에 교체하려다 버그로 다시 지연을 반복하면서 거의 5~6년을 소모했습니다. (09년 이전에 미드 CSI나 24에 나오는 시스템은 영화일 뿐이란 거죠 ;;)


사족의 사족

어쩌면 너무 당연한 이야기를 주저리 하는 것 같아서 망설였습니다. 특히 고수님들이 보시면 '훗' 웃어 넘길 부분이겠죠. 하지만, 처음 글이 소프트웨어 쪽 정보가 많이 부족하다고 느껴졌으며, 특히 계획에서 고려할 것 정보들이 부족하다고 느낍니다. 그래서 구지 이렇게 첨언합니다.

이런 질문에, 직접 개발을 위한 정보들 (APM 구축 및 구현)은 구하기 쉽습니다. 그리고 영문법 처럼 매우 명확한 부분이죠. 아마 half4u 님께서 직접 하실 부분은 아니지만 대락 '개발자들은 이렇게 움직이는군'이라고 파악하시는 부분에 유용할 겁니다. 여기까지가 구현 단계 의사 소통을 위한 기반 지식입니다.

그리고 프로젝트 진행 단계의 의사 소통은 소프트웨어 공학(Software Engineering) 분야로 분류되는데, '100개의 프로젝트가 있다면, 100개의 방법이 있다.'고 할만큼 경험에 의존한 부분입니다. 전문가로 나뉘는 부분은 구현 지식보다는 거의 이쪽 경험에 의존합니다. 공통의 좋은 습관들을 정리한 책들은 많은데 각자의 경험을 기반으로 해서 읽으시면 매우 모호할 것입니다.

제가 즐기는 애자일쪽 방법 요소들을 개발에 포함시키는 건 매우 유용하며 관련 서적을 통해서 간접 경험을 하실수 있을 겁니다. 지식의 시발점을 삼을 만한 링크는 다음과 같겠네요.

(스크럼, 익스트림 프로그래밍 정도 키워드로 검색하시면 한역 번도 있습니다. 이들 책은 매우 얇고 소설 읽듯이 타인의 간접 경험을 체험하실수 있을 겁니다. -스크럼 책 좋았습니다. ;; - 공익 사업이니, 역자들에게 연락하셔서 자문이나 식사 한끼 하는것도 한 방법이 되리라 생각합니다.)

화이팅 입니다. :)

half4u의 이미지

이미 접수된 요구사항만 봐도 기획(?)역할을 해야하는 제가 봐도 헉소리 나는 사항들이 많습니다.
대표적으로 회계파트에서는 결제부분이 '회계프로그램'과 자동으로 연동돼길 바라고 실무진에서는 '재고관리'와 연동해달라고 합니다.

그레서 말씀하신데로 가능한 '전체의 모습을 명확하게 기획'하되, 처음 목표는 할머니,할아버지 DB 통합관리로 한정하고 나머지 기능들은 점진적으로
시간을 두고 가상 시뮬레이션도 하면서 꼭 필요한 기능인지 검토하면서 추가하려고 합니다.

역시 핵심은 '지치지 않고 지속적으로 개발할 수 있는 환경을 만들어 나가는 것'이 핵심인거 같더군요.

p.s1. 혹시 앞서 말씀하셨던 비전문가 주도로 성공한 케이스가 FBI 센티널인가요? 이게 아니라면 그것두 좀 알려주시면 좋겠습니다만..^^

p.s2. 내가 더 알수록 알려주시는 사항들을 더 잘 받아들이는것 같습니다. 역자분에 버금가는분들께 물어볼 수 있는 정도의 내공을 쌓는데 더욱 정진하겠습니다.^^

익명 사용자의 이미지

DB설계가 제일 재밋슴 ㅎ

snowall의 이미지

다 떠나서, 가장 중요한건 기획하시는 분이 요구사항을 매우 명확하게 하고, 개발하기 시작한 후에는 변경하지 않는 겁니다.

요구사항이 명확할수록, 개발 중 수정사항이 적을수록, 위에 질문한 1, 2, 3, 4번 항목에 있어서 문제는 줄어듭니다.

개발에 있어서 가장 힘든건 불명확한 요구사항과 개발중에 계속해서 수정되는 내용이지 언어, DB설계, 서버 구축, 그정도는 어차피 맨날 하는 일이라 크게 어렵지 않습니다.

피할 수 있을때 즐겨라! http://melotopia.net/b

익명 사용자의 이미지

half4u님이 잘 모르시는 것은 부끄러운 것이 아니고 당연한 겁니다.
잘 알면 외주 줄 필요도 없지요.

요구사항이 약간 더 명확하면 여러가지로 검토할 수 있습니다.

* DB(데이터베이스)
- 구글 문서 도구, 구글 app engine 이용하는 방법
설명: 이 방법을 사용할 경우,

전문가1가 사람k-분야1 파일 저장
전문가2가 사람k-분야2 파일 저장
...
전문가n-1가 사람k-분야n-1 파일 저장
전문가n가 사람k-분야n 파일 저장.
 
k는 1에서 요양원 이용자 수의 범위.

각 전문가는 자신이 생성한 파일에 대하여 RW 권한
타인이 생성한 파일에 대하여 R 권한

자료 입력 프로그램은 요양원별, 이름별, 전문가 이름, 분야별로 검색 가능해야 함.
검색한 결과에 대해 수정 또는 보기 기능 있어야 됨.

보고서 출력 프로그램은 할아버지k에 대하여 분야1~n까지의 파일을 읽어서 새로운 보고서 파일 생성.

위의 프로그램은 웹 프로그램. 웹에서 실행 가능, 로컬에서 실행 가능.

장점: 유비보수 비용 상당히 적음. 인터넷이 가능하면 어디에서든 사용 가능, 스마트폰 사용 가능.

- 이미 나와 있는 위키 사이트 소스 이용하여 구축하여 이용하는 방법
위와 비슷함.

- MySQL 사용하여 직접 사이트 구축하는 방법
마찬가지로 위와 비슷하나 더 많이 프로그램 해야 됨. 정보 보호에 더 신경 써야 됨.
유지보수 비용 상승.

* 사용자 인터페이스
- 웹 브라우저.

구글이 망하지 않거나 다운되지 않는다는 가정하에 구글 문서 도구, 구글 app engine 추천함.

snowall의 이미지

위와 같은 내용의 기획서를 만드는데 나빌레라 님의 글이 도움이 될 것 같네요

http://kldp.org/node/120205

위의 글은 시리즈로 있으니까 끝까지 한번 읽어보세요

피할 수 있을때 즐겨라! http://melotopia.net/b

나빌레라의 이미지

앗!!
깜짝이야! ㅎㅎㅎㅎㅎ

^--^

----------------------
얇은 사 하이얀 고깔은 고이 접어서 나빌레라

half4u의 이미지

개발할때 어떻게 기획하시는지 처음으로 접하게 됐습니다.
정규 과정이 아니라 혼자할때 하는 방식이라고 전제하셨습니다만
기본사고방식은 정규 과정도 비슷하겠죠? ^^

half4u의 이미지

개인정보문제가 있기때문에 구글app은 아쉽지만 포기했습니다.ㅡㅡ;

하지만 익명님께서 말씀하신 구조로 갈수밖에 없을듯합니다.
다만 여기서 덧붙이면 (지금 공부하면서 요구사항에 추가중인 부분입니다만) 사람k-분야n의 DB를 각지점 서버에 분산(해당 지점 사람k-분야n만)배치하고 중앙서버에 백업서버구축.
지점내에서는 LAN이니까 해당서버 위주로 운영하고 중앙서버와는 VPN으로 묶어서 운영.

지점과 중앙간에 인터넷문제등으로 자료조회가 어려울때는 중앙에서 중앙백업서버 자료참고. 이때 마지막 업데이트후 내용변경 있을수 있다는 경고 팝업창 띄우기!

뭐..이런 식으로 정리중입니다..^^;

p.s. DB분산배치하는거 때문에 카산드라에 하둡까지 수박 겉핧기로 봤는데 저랑 상관없다는 사실 하루...만에 알았습니다...ㅜ.ㅠ

lateau의 이미지

프로젝트 자체를 오픈소스로 해버려도 재미있을 것 같은데요.

--
I think to myself...what a emerging world.

half4u의 이미지

말머리는 [완료]로 바꾸고 신변잡기적인 이야기는 자유게시판으로 가서 하겠습니다.
도와주신 익명,유명(?) 개발자분들께 앞으로도 도움바라며 다시한번 감사드립니다.

half4u의 이미지

설치, 활용에서 다른분에게 그리 유익한 내용은 아니고 개발자분들 보기엔 신변잡기적인 이야기에 가까우니
게시판을 자유게시판으로 바꾸겠습니다....^.^

jachin의 이미지

아무도 만들고 나서, 이후 운영에 대한 말씀을 안하셨길래 글 써봅니다.

아마도 서버가 필요하고,
서버의 운영과 구축한 인프라의 운영도 같이 유지할 수 있는 사람이 필요할 것 같습니다.
설명하신 내용에서 초기 비용외에 월 200만원 상당의 비용은 그러한 유지비용이 아닐까 생각합니다.
물론 잘 만들어져서 누구의 손도 타지 않게 된다면, 제일 좋은 모델이겠지만요. :)

하지만, 제가 생각하기에 '사회복지사', '영양사', '간호사', '요양보호사' 모두가 사용할 수 있는 좋은 소프트웨어를 만드려면 역시나 크나큰 노력과 지식, 자원이 필요하다고 생각됩니다. 익명분들께서 말씀해주신 것처럼, 기존의 공개된 (무료)서비스를 이용하는 것도 방법이긴 하지만, 아마 서로 문서를 공유하는 것 외의 서로의 정보를 '처리'해야 하는 부분도 있을거라 생각합니다. 가령 간호사가 약을 처방받은 것을 입력하고 식이요법이 필요하다고 썼지만, 영양사가 이 사실을 모르고 식사를 처리한다면 위험할 수도 있을테니까요. 물론 서로 정보를 자주 교환하면 되긴 하지만, 그러기 쉽지 않을테니, 될 수 있다면 서로가 실수를 하지 않도록 소프트웨어가 보조해줘야 한다고 생각합니다.

간단한 일이라면, 간단하고, 복잡한 일이라면, 복잡하겠네요. :)

누군가가 나서서 이 일이 처리되길 바라고 있으면 될까요? :)

half4u의 이미지

그렇게 복잡한 시스템을 모두 구현하려고하면 당연히 개발비용및 유지비용이 급상승할테고 의외의 버그도 많겠지요.

그레서 역시 핵심은 전산솔루션없이도 기존의 종이를 기반으로한 결제관리 시스템만으로 업무에 지장이 없도록 데이터베이스및 프로세스를 완성하고
이를 처음에는 부분적으로 예를들면 할아버지에게 새로운 진단명이 생겼는데 담당부서별로 불완전하게 업데이트가 돼는등의 문제를 해결하는 정도로
단순하게 만들어 기존 체계를 보조하는 수준에서 시작할 계획입니다.

그러면서 점진적으로 추가적인 요구사항을 갱신하여 반영하는 방향으로요.

요는 현재 서류기반 체계에서도 운용은 가능합니다.
다만 현재 계속 발생할여지가 있는 문제를 줄이면 효율이 높아지고 그만큼 할머니,할아버지들에대한 서비스 질이 올라갈거라 믿으며 추진하는겁니다.
(단적인예로 사회복지사 법정인원이 어르신 100분당 1명 채용인데 위와같은 서류작업때문에 50분당1명이상이 돼야 원활한 서비스가 가능하다는게 그동안
경험입니다. 처음은 사람쓰는게 더 효율적이지만 수용인원이 늘어나면서 전산화의 메리트가 부각된면도 있습니다.)

말은 그럴듯합니다만 결론은 한정된 자원에서 추진하려다보니 (ㅜ.ㅠ) 적극적으로 사용자쪽에서 개발자쪽에 협조하기위해 공부도하고 자료도
준비하면서 미비한부분은 운용으로 커버하겠다는거죠...ㅠ.ㅠ (아..재정에 압박이여...)

p.s 사실 월 유지비용 200만원이 결정적인 사유는 아니였습니다. 일단 해당업체의 시스템은 **요양원의 요구사항에 따라 개발된 사양으로 해당 요양원은 정부지원이
무지막지하기때문에 투입자본이나 인력을 매우 많이 소모하는 구조여서(예로 데이터입력만하는 입력사를 따로 채용하는등)직원수가 모시는 어르신들의 80% 가까이 돼서 우리측 결제시스템과 많이 달랐습니다.
그걸 도입하려면 사람이 옷에 맞추는것과같은 과정이 필요한거죠.
그리고 우리가 완전히 그업체 시스템으로 넘어간 다음에 해당업체에서 유지비용을 대폭 인상하거나 다른사유로 서비스를 중단했을때 대안이 없다는점도 치명적이였고요.