Thursday, January 11, 2007
Гүүр инженерийн мэдлэг
Саяхан шинээр сургалтанд явсан компанийн гишүүд болон японд энэ чиглэлээр сурж ажиллаж байгаа хүмүүс маань энэхүү блогийг үргэлжилүүлэн бичнэ гэж найдаж байна. Та бүхэн гүүр инженерийн талаар сурсан мэдсэн бүхнээ батжуулан энэхүү блогийг үргэлжилүүлэн бичихыг хичээнгүйлэн хүсэж байна.
Tuesday, October 24, 2006
Japanese Business Manners - Нэрийн хуудас солилцох
Анх удаагаа уулзаж байгаа хүмүүс нэрийн хуудсаа босч зогсож байгаад солилцох бөгөөд баруун гартаа нэрийн хуудсаа бариад солилцоно. Ингэхдээ нөгөө хүн нэрийг тань уншиж чадахуйц байлгахын тулд нэрийн хуудсаа түүн рүү харуулан байрлуулна. Харин нэг анхаарах ёстой зүйл нь тухайн хүнийхээ нэрийн хуудсыг харж байхад нь өөрийн бүсэлхийнээс доош байрлалд байлгаж болохгүй. Өөрөөр хэлбэл кармалчихаж болохгүй л гэсэн үг. Энэ нь тухайн хүнээ хүндэтгээгүй хэрэг болдог.
Sunday, October 22, 2006
Japanese Business Manners - Manners on the job
Хувцаслалт болон гадаад үзэмждээ анхаарах зүйлс
Японд ямарваа хүн ажил дээрээ байхдаа өөрийн гадаад төрх, ерөнхий үзэмж болон хувцаслалтдаа гойд анхаарах шаардлагатай байдаг бөгөөд энэ нь тухайн хүн бусдыг хүндэтгэдэг, ухаалаг гэдгийг нь илтгэж байдаг. Мөн үйлчлүүлэгчидтэй уулзахаар явахдаа ч өөрийн гадаад үзэмж болон хувцаслалтдаа анхаарснаар тэдэнд сайхан сэтгэгдлийг төрүүлж байдаг. Ингээд анхаарвал зохих зүйлсийг дурдвал :
Компани гэдэг маш олон зорилгоос бүрддэг. Тэдгээр зорилгыг ажил хэрэг болгохын тулд компаний нийт ажилжид эвсэгээр хамтран ажиллаж, мөн тэдгээр олон зорилгыг биелэхэд нь хөшүүрэг болж байдаг дэг журам, хэвшмэл ёсуудыг нарийн мөрдөж байх хэрэгтэй.
Учир нь компани гэдэг янз бүрийн үзэл бодол, чадвар, мэдлэг бүхий хөгшин залуу, эрэгтэй эмэгтэй хүмүүсийн нэгдэл билээ. Тэгэхээр тэд бүгд хоорондоо нэгэн баг мэт хамтран ажиллахын тулд нийтээр тогтсон хэм хэмжээг даган мөрдвөөс зохих билээ.
Бусадтай сайн харилцааг үүсгэхийн тулд :
Японд ямарваа хүн ажил дээрээ байхдаа өөрийн гадаад төрх, ерөнхий үзэмж болон хувцаслалтдаа гойд анхаарах шаардлагатай байдаг бөгөөд энэ нь тухайн хүн бусдыг хүндэтгэдэг, ухаалаг гэдгийг нь илтгэж байдаг. Мөн үйлчлүүлэгчидтэй уулзахаар явахдаа ч өөрийн гадаад үзэмж болон хувцаслалтдаа анхаарснаар тэдэнд сайхан сэтгэгдлийг төрүүлж байдаг. Ингээд анхаарвал зохих зүйлсийг дурдвал :
- Үсээ гоё засуулж, угааж самнасан байх бөгөөд хайш яйш харагдахгүй байх
- Өөрийн нүүр, шүд, чих, гараа цэвэрхэн байгаа эсэхийг дахин нэг нягтлах
- Хэт хээнцэр болон тод хурц өнгийн хувцас өмсөхөөс зайлсхийх
- Зангиа тань бусад хувцастайгаа зохицож байх
- Гутал тань цэвэрхэн гялалзаж байх
- Жижиг алчуур байнга авч явах
Компани гэдэг маш олон зорилгоос бүрддэг. Тэдгээр зорилгыг ажил хэрэг болгохын тулд компаний нийт ажилжид эвсэгээр хамтран ажиллаж, мөн тэдгээр олон зорилгыг биелэхэд нь хөшүүрэг болж байдаг дэг журам, хэвшмэл ёсуудыг нарийн мөрдөж байх хэрэгтэй.
Учир нь компани гэдэг янз бүрийн үзэл бодол, чадвар, мэдлэг бүхий хөгшин залуу, эрэгтэй эмэгтэй хүмүүсийн нэгдэл билээ. Тэгэхээр тэд бүгд хоорондоо нэгэн баг мэт хамтран ажиллахын тулд нийтээр тогтсон хэм хэмжээг даган мөрдвөөс зохих билээ.
Бусадтай сайн харилцааг үүсгэхийн тулд :
- Ажилчидтай найрсаг халуун дулаанаар мэндчилж байх
- Бусдын санаа бодлыг хүндэтгэж тэднийг байнга урмаар тэтгэж, зөв зүйл дээр нь сайшааж байх
- Бусдын нэрсийг мартахгүй цээжилж байх
- Ажлын цагийг ягштал баримталж, өглөө хоцрохгүй, орой цагаас эрт явахгүй байх
- Хувийн асуудлаа ажилтайгаа хольж хутгахгүй байх
- Үйлчлүүлэгчдийн нууцыг чандлан хадгалах
- Сандал ширээ болон бусад эд хогшлоо эмх цэгцтэй байлгах
- Аливаа асуудал тулгарвал заавал өмнө нь дээд тушаалын хүндээ мэдэгдэх
- Бусадтай нийцэн ажиллаж байгууллагынхаа нэгэн ажилсаг гишүүн нь байх
- Ажилдаа хариуцлагатай хандаж дуусгахын төлөө бүх арга замыг хэрэглэх
- Ажилдаа өөрийн сэтгэлийн эмоцоор хандаж болохгүй
- Өөрийн үүрэг ролийг гүнээ ухамсарлах
- Тайланг өөрийн дээд тушаалтанд байнга тавьж өөрийн ажлын үр дүнг илтгэж байх
- Заавар удирдамж, анхааруулгыг нь зөвөөр хүлээн авдаг байх
- Хамтран ажиллагсдынхаа талаар муугаар ярихгүй байх
- Өөрийн ажлын талаар гомдол мэдүүлэхгүй байх
- Зөвхөн ганц дээд албан тушаалтантай харьцаад байж болохгүй. Ялгаварласан хэрэг болно
- Амлалтаа биелүүлдэггүй
- Эелдэг бус
- Хоцордог
- Согтчоод зүй зохисгүй авир гаргадаг
- Мөнгөтэй холбоотой асуудалд дүрмээ баримталдаггүй
- Хэт эмоцтой
- Буслын талаар муулж ярьдаг
Wednesday, October 18, 2006
Төслийн удирдлага - Тойм
Төслийн удирдлага. Тойм 10/16
Төсөл гэдэг нь тодорхой хугацаанд тусгай зорилгод хүрэхийн тулд хийгдэж байгаа ажилуудыг тодорхой дараалалтай хийхийг хэлэнэ.
Төсөл нь ихэнхдээ энгийн жижиг ажилууд эсвэл төслүүдэд хуваагдан задардаг. Тухайн жижиг жижиг ажилуудыг ихэвчилэн 4 үе шатуудад хуваан хийдэг. Эндээр үе шатууд нь :
--- 1. Стратейг төлөвлөгөөний шат.
Стратейг төлөвлөгөө хэсэгт тухайн төслийг захиалагчаас авахын тулд тодорхой төлөвлөгөө бичиг баримтуудыг боловсруулан тендерт оролцох хэсэг.
Энэ шатанд дараагийн шатуудад хийгдэн гарах бүтээгдэхүүнийг судлан гол зорилгоо тодорхойлон гаргах хэсэг юм. Энэ хэсэгт захиалагч тал болон гүйцэтгэгч талуудын төлөөлөлчид хоорондоо хэрэлцэн захиалагч талийн хийлгэх бүтээгдэхүүнийг нарийвчлан тодорхойлуулж авасаны үндсэн дээр захиалагчийн хийлгэх бүтээгдэхүүний шаардалга дээр үндэслэн гаргасан санал болгож буй бичиг баримт-ийг хийх юм. Энэ бичигт дараар зүйлсийг анхаарч тусгасан байх хэрэгтэй.
--- 2. Загварчилах шат.
Энэ үе шатанд нь Work Breakdown Structure (WBS), нөөций төлөвлөлт, хэмжилт, төлөвлөгөө (schedule), Эрсдэлийн төлөвлөгөө зэрэг ажлуудаас тогтоно.
Хамгийн эхэнд (WBS) ийг гаргах хэсэг энэ нь төслийн ажлуудын оролт гаралт болгоныг нь нарийн тооцож тухайн ажлын хамрах хүрээ зэргийг, харилцан хамаарал зэргээр нь ангилан мод хэлбэрийн бүтцэд оруулан гаргадаг.
Нөөцийн төлөвлөлт энэ ажил нь өмнө нь гаргаж авсан WBS дээр жагсаасан ажилууд дээрээ хүний нөөц болон, материаллаг нөөцөө хувиарлан төвөллөх. Мэдээж ажлуудынхаа хэмжээ, зэрэглэл, хүмүүсийнхээ гүйцэгэл зэргийг нь харгалзан хүмүүстээ хувиарлана.
Хэмжилт. Хэмжилт өмнө нь гаргасан WBS дээрх бүх ажлуудынхаа хийхэд шаардагдах хугацаа, түүнд зарцуулагдах өртөгийг нь гаргана. Үүнийг гаргахдаа чанар, хэмжээ, бүтээмж нөөцийнхөө нэгж өртөгийн тооцон үзэж гаргах хэрэгтэй.
Төлөвлөгөө. Төлөвлөгөөнд та WBS дээр гаргасан ажлуудаа шинж чанар, харилцан хамаарал, хараат байдал зэргээр нь эрэмбэлээд Gannt Chart эсвэл Network диаргамм дээр оруулан зурна.
Эрсдэлийн төлөвлөгөө. Тухайн төслийн хувьд хамгийн их эргэлзэж байгаа бас төлөвлөж болохгүй ажлууд байдаг. Эдгээрийг эрсдэл гэх бөгөөд төслийн аль ч шатанд тохиолдож болно. Тийм учираас хийгдэж байгаа ажилуудад ямар ямар эрсдэл гарч болох талаар гарсан тохиолдолд яаж зохицуулах талаар төлөвлөсөн байх хэрэгтэй. Мэдээж бүгдийг нь тооцоно гэдэг бол хүнд. Хамгийн ноцтой төслийн биелэлтэнд нөлөөлөж болох эрсдэлүүдийг зайлшгүй тооцсон байх хэрэгтэй.
Энэ хэсэгт дараах бичиг баримтийг боловсруулан гаргах хэрэгтэй.
--- 3. Хэрэгжүүлэх шат
Тухайн төслийн хэрэгжүүлэх шатанд төслийн манажерийн хийх ажил нь төслийн явцийг сайн хянах. Хэрвээ төслийн явацыг бүгдийг нь төлөвлөчихсөн бол хэрхэн явагдаж байгааг нь судлана. Хэрвээ ямар нэг өөрчлөлт зайлшгүй орох хэрэгтэй болсон бол түүнээс суралцах хэрэгтэй дараа яавал энэ алдааг гаргахгүй байх хэрэгтэй. Менежер хүн ямао асуудал эсвэл ямар бэрхшээл гарч болох талаар урьдчилан зөгдөж чаддаг байх хэрэгтэй.
--- 4. Төгсгөлийн шат
Төслийн менежерийн хувьд төсөл нь ихэнхдээ тийм амар дуусахгүй. Хялбар баараггүй гэсэн ажлуудаа эхлээд дуусгаж хамгийн чухал найдвартай хийх ёстой ажилаа сүүл хүртэл нь хийж дуусгах хэрэгтэй.
Төгсгөлийн шатанд хийх үндсэн ажилууд:
Төсөл гэдэг нь тодорхой хугацаанд тусгай зорилгод хүрэхийн тулд хийгдэж байгаа ажилуудыг тодорхой дараалалтай хийхийг хэлэнэ.
Төсөл нь ихэнхдээ энгийн жижиг ажилууд эсвэл төслүүдэд хуваагдан задардаг. Тухайн жижиг жижиг ажилуудыг ихэвчилэн 4 үе шатуудад хуваан хийдэг. Эндээр үе шатууд нь :
- Стратейг төлөвлөгөө
- Загварчилах шат
- Төлөвлөх шат
- Хэрэгжүүлэх шат
- Дуусгах шат
--- 1. Стратейг төлөвлөгөөний шат.
Стратейг төлөвлөгөө хэсэгт тухайн төслийг захиалагчаас авахын тулд тодорхой төлөвлөгөө бичиг баримтуудыг боловсруулан тендерт оролцох хэсэг.
Энэ шатанд дараагийн шатуудад хийгдэн гарах бүтээгдэхүүнийг судлан гол зорилгоо тодорхойлон гаргах хэсэг юм. Энэ хэсэгт захиалагч тал болон гүйцэтгэгч талуудын төлөөлөлчид хоорондоо хэрэлцэн захиалагч талийн хийлгэх бүтээгдэхүүнийг нарийвчлан тодорхойлуулж авасаны үндсэн дээр захиалагчийн хийлгэх бүтээгдэхүүний шаардалга дээр үндэслэн гаргасан санал болгож буй бичиг баримт-ийг хийх юм. Энэ бичигт дараар зүйлсийг анхаарч тусгасан байх хэрэгтэй.
- Бидний зорилго санаанд нь нийцэх эсэх
- Үнийн ашигтай санал
- Захиалагчийн сэтгэл ханамж
- Бизнессийн ирээдүйн стратейг
- Ажлыг хийх бүтэц (Байгууллагын хийх хүмүүсийн бүтэц болон харилцах хүн гэх мэт)
- Шаардлагууд
--- 2. Загварчилах шат.
Энэ үе шатанд нь Work Breakdown Structure (WBS), нөөций төлөвлөлт, хэмжилт, төлөвлөгөө (schedule), Эрсдэлийн төлөвлөгөө зэрэг ажлуудаас тогтоно.
Хамгийн эхэнд (WBS) ийг гаргах хэсэг энэ нь төслийн ажлуудын оролт гаралт болгоныг нь нарийн тооцож тухайн ажлын хамрах хүрээ зэргийг, харилцан хамаарал зэргээр нь ангилан мод хэлбэрийн бүтцэд оруулан гаргадаг.
Нөөцийн төлөвлөлт энэ ажил нь өмнө нь гаргаж авсан WBS дээр жагсаасан ажилууд дээрээ хүний нөөц болон, материаллаг нөөцөө хувиарлан төвөллөх. Мэдээж ажлуудынхаа хэмжээ, зэрэглэл, хүмүүсийнхээ гүйцэгэл зэргийг нь харгалзан хүмүүстээ хувиарлана.
Хэмжилт. Хэмжилт өмнө нь гаргасан WBS дээрх бүх ажлуудынхаа хийхэд шаардагдах хугацаа, түүнд зарцуулагдах өртөгийг нь гаргана. Үүнийг гаргахдаа чанар, хэмжээ, бүтээмж нөөцийнхөө нэгж өртөгийн тооцон үзэж гаргах хэрэгтэй.
Төлөвлөгөө. Төлөвлөгөөнд та WBS дээр гаргасан ажлуудаа шинж чанар, харилцан хамаарал, хараат байдал зэргээр нь эрэмбэлээд Gannt Chart эсвэл Network диаргамм дээр оруулан зурна.
Эрсдэлийн төлөвлөгөө. Тухайн төслийн хувьд хамгийн их эргэлзэж байгаа бас төлөвлөж болохгүй ажлууд байдаг. Эдгээрийг эрсдэл гэх бөгөөд төслийн аль ч шатанд тохиолдож болно. Тийм учираас хийгдэж байгаа ажилуудад ямар ямар эрсдэл гарч болох талаар гарсан тохиолдолд яаж зохицуулах талаар төлөвлөсөн байх хэрэгтэй. Мэдээж бүгдийг нь тооцоно гэдэг бол хүнд. Хамгийн ноцтой төслийн биелэлтэнд нөлөөлөж болох эрсдэлүүдийг зайлшгүй тооцсон байх хэрэгтэй.
Энэ хэсэгт дараах бичиг баримтийг боловсруулан гаргах хэрэгтэй.
- Хүний нөөцийн хувиарлалт
- Хөгжүүлэлтийн хамрах хүрээ
- Төлөвлөгөө
- Төсөв
- Эрсдэлийн төлөвлөгөө
- Хөгжүүлэлтийн орчин болон ашиглах багажуудын хэлэлцэж тогтсон баримт.
--- 3. Хэрэгжүүлэх шат
Тухайн төслийн хэрэгжүүлэх шатанд төслийн манажерийн хийх ажил нь төслийн явцийг сайн хянах. Хэрвээ төслийн явацыг бүгдийг нь төлөвлөчихсөн бол хэрхэн явагдаж байгааг нь судлана. Хэрвээ ямар нэг өөрчлөлт зайлшгүй орох хэрэгтэй болсон бол түүнээс суралцах хэрэгтэй дараа яавал энэ алдааг гаргахгүй байх хэрэгтэй. Менежер хүн ямао асуудал эсвэл ямар бэрхшээл гарч болох талаар урьдчилан зөгдөж чаддаг байх хэрэгтэй.
--- 4. Төгсгөлийн шат
Төслийн менежерийн хувьд төсөл нь ихэнхдээ тийм амар дуусахгүй. Хялбар баараггүй гэсэн ажлуудаа эхлээд дуусгаж хамгийн чухал найдвартай хийх ёстой ажилаа сүүл хүртэл нь хийж дуусгах хэрэгтэй.
Төгсгөлийн шатанд хийх үндсэн ажилууд:
- Төслийн хүрээнд хийгдсэн бүх дууссан ажлуудыг баталгаажуулах
- Хийсэн бүтээгдэхүүн ба гэрээний заагдсан зүйлсийн гүйцэтгэлийн баталгаажуулах
- Төслийн бүх файлуудыг эмхлэж хадгалах
- Захиалагчид хүлээлгэж өгөх бүтээгдэхүүнд хийсэн зүйлс бүгд орсон эсэхийг шалгаж баталгаажуулах
- Төслийн бүрэн тайлбан ба төслийн үнэлгээний тайлангуудыг гаргах
Japanese Business Manners - Business Conversation
Business Conversation-ий үед баримтлах хэвшмэл ёсууд :
- Ярихдаа :
- Ярихдаа :
- Зорилгоо зөв тодорхойлж, ярианыхаа гол гол point-уудаа хооронд энгийн цэвэрхэн уялдуулан ярих
- Чухал point-уудыг баталгаажуулан хэлж байх. Үүнд : 5W2H (When, Who, Where, What, Wht, How, How much) -ийг мөрдлөг болгоно
- Дууны өнгө болон ярих хурдаа хамгийн тохиромжтой хэмжээнд байлгахын сацуу үгээ тод хэлэх
- Ярилцаж байхдаа ярианд оролцогч бусад талуудын байр суурийг байнга анхааралдаа авч байх
- Тэнд байгаа бүх хүнд ойлгогдохуйц тийм үгсийг сонгон авч хэрэглэх (хамаагүй мэргэжлийн үгс болон гадаад үгсийг замбараагүйгээр хольж хэрэглэвэл үл ойлголцол үүснэ)
- Хэнтэй ярьж байгаагаасаа хамааруулаад хэрхэн яаж харьцахаа тохируулах (жишээ нь үйлчлүүлэгчтэй, даргатайгаа, хамтран ажиллагсадтайгаа гэх мэтээр өөр өөрөөр харьцана.)
- Өөртөө итгэлтэйгээр бүх үгээ тод цэвэр хэлэх
- Анхааралтай сонсож яригдаж байгаа зүйлийг зөв ойлгох
- Ярьж байгаа хүний зүг харан ойлгож байгаа гэдгээ илэрхийлэхийн тулд байнга толгой дохих
- Яриаг нь тасалдуулахгүй байх
- Хэрвээ чухал гэж үзвэл ажил хэрэгт холбогдолтой асуултыг л асуух
- Тухайн хүний ярианд дурдагдсан чухал гэж үзсэн point-уудыг байнга баталжуулан авч байх
- Sonkeigo : Өөрөөсөө албан тушаал өндөр эсвэл нийгмийн статус өндөр хүмүүстэй харьцахдаа хэрэглэх үгс
- Kenjogo : Өөрөөсөө өндөр зэрэглэлийн хүнд өөрийн тухай ярихдаа хэрэглэх үгс
- Teineigo : Бусад хүмүүсийн зүг хандан ярихдаа хэрэглэх эелдэг үгс
Sunday, October 15, 2006
Making a Proposal
Making a Proposal сэдэвтэй хичээл оров. Энэ хичээл нь үндсэндээ бол программ бичих тендер зарласан үед тэр тендерт оролцохын тулд бэлдэж байгаа материал юм. Японд программ хийлгэхийг хүссэн компани нь өөрийн одоо байгаа хүндрэл болон ямар систем хийлгэх хүсэлтэй байгаагаа товч бичээд программ хангамжийн компаниудад өгдөг юм байна. Түүнийг нь судлан үзэсэний дараа доорхи материалыг захиалагчид бэлдэн өгдөг юм байна. Захиалагч нь тэдгээр материалуудтай танилцаад аль сайн санал тавьсан компанийг нь сонгож программаа хийлгэдэг юм байна. Материалын бэлдэхийн тулд мэдээж захиалагч компанийн хүнтэй цаг тохирч уулзан нарийн нарийн зүйлсийг нь тодорхой болгон мэдэж авна.
Энэ тендэрийн материалд байх ёстой агуулагууд буюу гарчигийг нь тайлбарлаяа.
1. Танилцуулга
Үүнд захиалагч компанийн хийлгэхийг хүссэн системийн талаар дэлгэрэнгүй бичнэ. Өөрийн компанийн санал болгож буй системийн зорилго болон, хамрах хүрээг дэлгэрэнгүй бичнэ.
2. Орчин нөхцөл
Энэ хэсэгт одоогийн байгаа системийг нь тайлбарлаж бичихээс гадна. Ямар ямар шаардлага байгааг нь тодруулан гаргаж ирнэ.
3. Санал болгож буй шийдэл.
Компанийхаа санал болгож буй шийдэлийн талаар дэлгэрэнгүй бичнэ. Үүнд Ерөнхий шийдэл, Шийдэлүүдийн хамрах хүрээ зэрэг байхаас гадна.
Тухайн бүтээгдэхүүний талаар фунцнал биш шаардлагуудыг нь тодорхойлоно. - Найдвартай ажиллагаа
- Чанар
- Хэрэглэхэд хялбар байдал.
- Дэмжлэг үзүүлэх байдал
зэрэгийг тодорхойлож өгсөн байх хэрэгтэй. Хэт их мэргэжлийг үг хэллэг ашиглахгүй байсан дээр аль болох энгийн ямар ч хүн ойлгохоор бэлдсэн материал бэлдэх хэрэгтэй. Захиалагч компанийн хүмүүс IT ийн мэдлэгэгүй хүн учираас тэр хүнд ойлгогдохоор байх ёстой.
4. Системийн хэлбэр
Үүнд системийн нэгжүүдийг хоорондын харилцаа, үүргийг тодорхойлсон диаграмм зураг. Түүний тайлбар. Системийн нэгжүүдийн техникийн үзүүлэлтүүд болон шаардлагатай программ хангамжуудийн жагсаалтыг харуулсан жагсаалт.
5. Төслийн төлөвлөгөө
Үүнд төслийн ерөнхий төлөвлөгөө, Хийх багийн гишүүд, Үйл ажиллагаанууд, Ямар загвараар төслийг хэрэгжүүлэх гэж байгаа гэх мэт зүйлсийг дэлгэрэнгүй оруулаж өгөх хэрэгтэй.
6. Хязгаарлалтууд ба Хамааралгүй зүйлсүүд
Энэ хэсэг бас чухал. Төсөл хэрэгжих байх үед захиалагч эрх болон үүргийг нь тодорхойлож өгсөн байх хэрэгтэй.
Жишээ нь: Захиалагч тал нь төсөл хэрэгжиж эхлээд 14 хоногийн дотор шаардлагатай өөрчлөлтүүдээ хийлгүүлэж болно. 14 хоногоос хойш томоохон өөрчлөлт хийлгэх тохиолдолд үнэ болон хугацаан дээрээ эргэж тохиролцоно. гэх байдалаар тусгаж өгөх хэрэтгэй. Тэхгүй бол төсөл амжилтгүй болох үүд хаалга нээгдэнэ.
7. Хаармаарал болон Таамаглал
Энэ хэсэгт зарим таамаглаж байгаа зүйлсээ бичих хэрэгтэй. Жишээ нь Бидний хийж байгаа бүтээгдэхүүн нь ийм ийм шаардлага хангасан компютер дээр ажиллана гэх мэт.
Жишээ нь:
XXX System is available under the assumption that
- Web Browser of Customer side: IE4.0+, Mozilla3.0+, Firefox1.0+
- OS of Customer side: Windows 98/2000/XP, Linux
8. Хөрөнгө оруулалт
Энэ хэсэгт хөрөнгө оруулалт буюу нийт төслийн хугацаанд хийгдэж байгаа ажилуудын үнэ. Төсөвлөсөн мөнгийн хэрхэн зарцуулах талаарх тайланг оруулаж өгөх хэрэгтэй.
Мөн цаашиг үзүүлэх үйлчилгээнүүдийнхээ үнэ болон суурилуулалтанд зарцуулах зардал зэргийг тусгасан байвал сайн.
9. Нөхцөлүүд ба Үндэслэл
Энэ хэсэгт тухайн бүтээгдэхүүнд цаашид ямар нөхцөлд ямар үйлчилгээ үзүүлэх вэ гэдэгийг тусгаж өгнө.
Жишээ 1.
2 жилийн дотор алдаа гарсан тохиолдолд үнэгүй засаж өгнө.
Жишээ 2.
Программаас хамаараагүй үйлдэлийн системээс ч юумуу бусад осол гамшигийн үед 1 удаа үнэгүй сэргээж өгнө.
10. Нэмэлт
Өөрийн компанийн танилцуулга, Туршилга, Бүтээлүүд зэргийг оруулаж болно.
Эдгээрийн дараалал нь чухал бөгөөд зарим хэсэгүүд нь байхгүй байж болно. Гол нь захиалагч компани сонголт хийхдээ аль сайн санал тависан сайн дэмжлэг үзүүлэх, хэр найдвартай компани зэргээр нь үнэлэх учираас эдгээр зүйлүүд байвал итгэлтэйгээр танай компанийг сонгох юм.
Энэ тендэрийн материалд байх ёстой агуулагууд буюу гарчигийг нь тайлбарлаяа.
1. Танилцуулга
Үүнд захиалагч компанийн хийлгэхийг хүссэн системийн талаар дэлгэрэнгүй бичнэ. Өөрийн компанийн санал болгож буй системийн зорилго болон, хамрах хүрээг дэлгэрэнгүй бичнэ.
2. Орчин нөхцөл
Энэ хэсэгт одоогийн байгаа системийг нь тайлбарлаж бичихээс гадна. Ямар ямар шаардлага байгааг нь тодруулан гаргаж ирнэ.
3. Санал болгож буй шийдэл.
Компанийхаа санал болгож буй шийдэлийн талаар дэлгэрэнгүй бичнэ. Үүнд Ерөнхий шийдэл, Шийдэлүүдийн хамрах хүрээ зэрэг байхаас гадна.
Тухайн бүтээгдэхүүний талаар фунцнал биш шаардлагуудыг нь тодорхойлоно. - Найдвартай ажиллагаа
- Чанар
- Хэрэглэхэд хялбар байдал.
- Дэмжлэг үзүүлэх байдал
зэрэгийг тодорхойлож өгсөн байх хэрэгтэй. Хэт их мэргэжлийг үг хэллэг ашиглахгүй байсан дээр аль болох энгийн ямар ч хүн ойлгохоор бэлдсэн материал бэлдэх хэрэгтэй. Захиалагч компанийн хүмүүс IT ийн мэдлэгэгүй хүн учираас тэр хүнд ойлгогдохоор байх ёстой.
4. Системийн хэлбэр
Үүнд системийн нэгжүүдийг хоорондын харилцаа, үүргийг тодорхойлсон диаграмм зураг. Түүний тайлбар. Системийн нэгжүүдийн техникийн үзүүлэлтүүд болон шаардлагатай программ хангамжуудийн жагсаалтыг харуулсан жагсаалт.
5. Төслийн төлөвлөгөө
Үүнд төслийн ерөнхий төлөвлөгөө, Хийх багийн гишүүд, Үйл ажиллагаанууд, Ямар загвараар төслийг хэрэгжүүлэх гэж байгаа гэх мэт зүйлсийг дэлгэрэнгүй оруулаж өгөх хэрэгтэй.
6. Хязгаарлалтууд ба Хамааралгүй зүйлсүүд
Энэ хэсэг бас чухал. Төсөл хэрэгжих байх үед захиалагч эрх болон үүргийг нь тодорхойлож өгсөн байх хэрэгтэй.
Жишээ нь: Захиалагч тал нь төсөл хэрэгжиж эхлээд 14 хоногийн дотор шаардлагатай өөрчлөлтүүдээ хийлгүүлэж болно. 14 хоногоос хойш томоохон өөрчлөлт хийлгэх тохиолдолд үнэ болон хугацаан дээрээ эргэж тохиролцоно. гэх байдалаар тусгаж өгөх хэрэтгэй. Тэхгүй бол төсөл амжилтгүй болох үүд хаалга нээгдэнэ.
7. Хаармаарал болон Таамаглал
Энэ хэсэгт зарим таамаглаж байгаа зүйлсээ бичих хэрэгтэй. Жишээ нь Бидний хийж байгаа бүтээгдэхүүн нь ийм ийм шаардлага хангасан компютер дээр ажиллана гэх мэт.
Жишээ нь:
XXX System is available under the assumption that
- Web Browser of Customer side: IE4.0+, Mozilla3.0+, Firefox1.0+
- OS of Customer side: Windows 98/2000/XP, Linux
8. Хөрөнгө оруулалт
Энэ хэсэгт хөрөнгө оруулалт буюу нийт төслийн хугацаанд хийгдэж байгаа ажилуудын үнэ. Төсөвлөсөн мөнгийн хэрхэн зарцуулах талаарх тайланг оруулаж өгөх хэрэгтэй.
Мөн цаашиг үзүүлэх үйлчилгээнүүдийнхээ үнэ болон суурилуулалтанд зарцуулах зардал зэргийг тусгасан байвал сайн.
9. Нөхцөлүүд ба Үндэслэл
Энэ хэсэгт тухайн бүтээгдэхүүнд цаашид ямар нөхцөлд ямар үйлчилгээ үзүүлэх вэ гэдэгийг тусгаж өгнө.
Жишээ 1.
2 жилийн дотор алдаа гарсан тохиолдолд үнэгүй засаж өгнө.
Жишээ 2.
Программаас хамаараагүй үйлдэлийн системээс ч юумуу бусад осол гамшигийн үед 1 удаа үнэгүй сэргээж өгнө.
10. Нэмэлт
Өөрийн компанийн танилцуулга, Туршилга, Бүтээлүүд зэргийг оруулаж болно.
Эдгээрийн дараалал нь чухал бөгөөд зарим хэсэгүүд нь байхгүй байж болно. Гол нь захиалагч компани сонголт хийхдээ аль сайн санал тависан сайн дэмжлэг үзүүлэх, хэр найдвартай компани зэргээр нь үнэлэх учираас эдгээр зүйлүүд байвал итгэлтэйгээр танай компанийг сонгох юм.
About Brain Storming, KJ Method, Fish Bone diagram
Багш маань бид нараар ямар нэг teamWork хийлгэхдээ Brain Storming, KJ Method, Fish Bone диаграм гэсэн 3 зүйлийг их ашиглуулж байгаа тул эдгээрийн талаар та бүхэндээ хургэе гэж бодлоо.
Brain Storming :
Энэ нэр томъёог манай компанийхан бүгдээрээ мэддэг гэж бодож байна. Японд ч өргөн ашиглах юм. Ямар нэг юм болвол шууд л Brain Storming хийе гэнэ. Brain Storming-ийг товч тодорхойлбол юуны өмнө багийн гишүүд тойрж суугаад ямар зүйлийн талаар ярих гэж байгаагаа хоорондоо ярилцаж limit ээ тогтоож өгнө. Өөрөөр хэлбэл өнөөдөр юуны талаар хэлэлцэх гэж байгаа болон ямар үр дүнг хүсэн хүлээж байгаа вэ гэдгээ ярилцана гэсэн үг. Дараа нь тэрхүү асуудлыг шийдэхийн тулд хүн бүр өөрийн санаа бодлыг хэлэх бөгөөд хэдэн ч санал санаачлага хэлж болно. Эсвэл хэлэхийн өмнө бүгд жижиг жижиг цааснууд дээр өөрийн шинэ санаа тус бүрээ бичээд дараа нь тайлбарлаж болно. Энд нэг гол баримтлах зарчим нь яг Brain Storming-ийн уеэр "no-criticism" байх ёстой. Өөрөөр хэлбэл хэн ч хэнийг чи буруу юм хэлчихлээ ч гэх юмуу эсвэл тухайн хүний яриаг тасалдуулж өөрийн comment-оо хэлж шүүмжилдэггй. Ингэснээр ямар нэг дүрэм журамд баригдалгүйгээр тухайн хүн чөлөөтэй сэтгэн бодож түүнийгээ илэрхийлэх боломж олдоно гэсэн үг. Brain Storming-оос гарах үр дун нь гэвэл маш олон тооны шинэ санаанууд болон асуудлыг шийдэх арга замууд байдаг. Энэ арга тун үр дүнтэй арга мэт санагдлаа. Гол давуу тал нь богино хугацаанд их мэдээллийг багийн гишүүдээс цуглуулах боломжтой.
KJ Method :
Анх Японд үүссэн аргачлал бөгөөд орчин цагийн Японы чанарын менежмэнтийн "7 багаж"-ийн нэг гэгддэг.
Энэхүү аргачлалын гол зорилго : Brain Storming-оор цугларсан олон тооны санал санаачлагуудыг эмхэлж цэгцлэн ангилж бүлэглэх.
Хэрхэн ашиглах талаар товч дурдал :
- Эхлээд хоорондоо төсөөтэй санаануудыг олж хамтад нь байрлуулна. Үүний үр дүнд хэд хэдэн бүлэг үүснэ.
- Хэрэв давхардсан эсвэл ач холбогдол багатай санаанууд байвал түүнийг устгана. Үр дүнд нь илүү дутуу юмгүй хэд хэдэн эмхлэгдсэн бүлэг үүснэ.
- Тухайн бүлгүүддээ оновчтой нэр өгнө. Үр дүнд нь нэрнээс нь хараад агуулгыг нь мэдэж болохуйц хэд хэдэн бүлгүүд үүснэ. Ингээд л болоо. Энэ нь мөн brain storming-ийн адил тун үр дүнтэй арга юм шиг надад санагдсан. Brain Storming болон KJ Method-ийг хэд хэд яг практик дээр ашигласны хувид жирийн хэлэлцүүлгээс ямар ч байсан хугацаа бага зарж байгааг нь мэдэрсэн билээ.
FishBone Diagram:
Япончуудын бас нэг өргөн ашигладаг аргачлалуудын нэг бөгөөд анх Каору Ишигава гэгч 1960 аад оны үед энэхүү диаграмыг хэрэглэсэн тул Ишигавагийн диаграм гэх нь ч бий. Мөн л чанарын мемежментийн 7 үндсэн багажийн нэг гэгддэг. Хэлбэр дүрснээсээ болоод нийтэд FishBone diagram (загасны ясан диаграм) гэж алдаршжээ.
Диаграмын гол зорилго нь тодорхой нэг үйл явдлын учир шалтгааныг үзүүлэхэд оршино.
Жишээлбэл "Offshore project failure" гээд сэдэв байлаа гэхэд Offshore ажил яагаад нурж болох тухай бүх хүчин зүлийг ангилан үзүүлнэ гэсэн үг. Ийнхүү ангилахдаа хамгийн гол хэдэн хүчин зүйлийг тулгуур болгон авч тэдгээрийг загасны том яснууд гэж нэрлэх ба тэдгээр гол хүчин зүйлд нөлөөлөх түүний жижиг яснууд гэж үзнэ. Ихэнх FishBone диаграмыг зурахад ажиглагддаг нийтлэг хэдэн хүчин зүйлүүд байдаг ба тэдгээрийг 4M, 4P, 4S гэж хураангуйлан нэрлэнэ.
Доор жишээ болгон энд дадлага болгон хийсэн fishBone diagram-уудын нэгийг үзүүлж байна. Сэдэв нь "Offshore project failure".
Brain Storming :
Энэ нэр томъёог манай компанийхан бүгдээрээ мэддэг гэж бодож байна. Японд ч өргөн ашиглах юм. Ямар нэг юм болвол шууд л Brain Storming хийе гэнэ. Brain Storming-ийг товч тодорхойлбол юуны өмнө багийн гишүүд тойрж суугаад ямар зүйлийн талаар ярих гэж байгаагаа хоорондоо ярилцаж limit ээ тогтоож өгнө. Өөрөөр хэлбэл өнөөдөр юуны талаар хэлэлцэх гэж байгаа болон ямар үр дүнг хүсэн хүлээж байгаа вэ гэдгээ ярилцана гэсэн үг. Дараа нь тэрхүү асуудлыг шийдэхийн тулд хүн бүр өөрийн санаа бодлыг хэлэх бөгөөд хэдэн ч санал санаачлага хэлж болно. Эсвэл хэлэхийн өмнө бүгд жижиг жижиг цааснууд дээр өөрийн шинэ санаа тус бүрээ бичээд дараа нь тайлбарлаж болно. Энд нэг гол баримтлах зарчим нь яг Brain Storming-ийн уеэр "no-criticism" байх ёстой. Өөрөөр хэлбэл хэн ч хэнийг чи буруу юм хэлчихлээ ч гэх юмуу эсвэл тухайн хүний яриаг тасалдуулж өөрийн comment-оо хэлж шүүмжилдэггй. Ингэснээр ямар нэг дүрэм журамд баригдалгүйгээр тухайн хүн чөлөөтэй сэтгэн бодож түүнийгээ илэрхийлэх боломж олдоно гэсэн үг. Brain Storming-оос гарах үр дун нь гэвэл маш олон тооны шинэ санаанууд болон асуудлыг шийдэх арга замууд байдаг. Энэ арга тун үр дүнтэй арга мэт санагдлаа. Гол давуу тал нь богино хугацаанд их мэдээллийг багийн гишүүдээс цуглуулах боломжтой.
KJ Method :
Анх Японд үүссэн аргачлал бөгөөд орчин цагийн Японы чанарын менежмэнтийн "7 багаж"-ийн нэг гэгддэг.
Энэхүү аргачлалын гол зорилго : Brain Storming-оор цугларсан олон тооны санал санаачлагуудыг эмхэлж цэгцлэн ангилж бүлэглэх.
Хэрхэн ашиглах талаар товч дурдал :
- Эхлээд хоорондоо төсөөтэй санаануудыг олж хамтад нь байрлуулна. Үүний үр дүнд хэд хэдэн бүлэг үүснэ.
- Хэрэв давхардсан эсвэл ач холбогдол багатай санаанууд байвал түүнийг устгана. Үр дүнд нь илүү дутуу юмгүй хэд хэдэн эмхлэгдсэн бүлэг үүснэ.
- Тухайн бүлгүүддээ оновчтой нэр өгнө. Үр дүнд нь нэрнээс нь хараад агуулгыг нь мэдэж болохуйц хэд хэдэн бүлгүүд үүснэ. Ингээд л болоо. Энэ нь мөн brain storming-ийн адил тун үр дүнтэй арга юм шиг надад санагдсан. Brain Storming болон KJ Method-ийг хэд хэд яг практик дээр ашигласны хувид жирийн хэлэлцүүлгээс ямар ч байсан хугацаа бага зарж байгааг нь мэдэрсэн билээ.
FishBone Diagram:
Япончуудын бас нэг өргөн ашигладаг аргачлалуудын нэг бөгөөд анх Каору Ишигава гэгч 1960 аад оны үед энэхүү диаграмыг хэрэглэсэн тул Ишигавагийн диаграм гэх нь ч бий. Мөн л чанарын мемежментийн 7 үндсэн багажийн нэг гэгддэг. Хэлбэр дүрснээсээ болоод нийтэд FishBone diagram (загасны ясан диаграм) гэж алдаршжээ.
Диаграмын гол зорилго нь тодорхой нэг үйл явдлын учир шалтгааныг үзүүлэхэд оршино.
Жишээлбэл "Offshore project failure" гээд сэдэв байлаа гэхэд Offshore ажил яагаад нурж болох тухай бүх хүчин зүлийг ангилан үзүүлнэ гэсэн үг. Ийнхүү ангилахдаа хамгийн гол хэдэн хүчин зүйлийг тулгуур болгон авч тэдгээрийг загасны том яснууд гэж нэрлэх ба тэдгээр гол хүчин зүйлд нөлөөлөх түүний жижиг яснууд гэж үзнэ. Ихэнх FishBone диаграмыг зурахад ажиглагддаг нийтлэг хэдэн хүчин зүйлүүд байдаг ба тэдгээрийг 4M, 4P, 4S гэж хураангуйлан нэрлэнэ.
- 4M : Methods, Machines, Materials, Man-Power
- 4P : Place, Procedure, People, Policies
- 4S : Surroundings, Suppliers, Systems, Skills
Доор жишээ болгон энд дадлага болгон хийсэн fishBone diagram-уудын нэгийг үзүүлж байна. Сэдэв нь "Offshore project failure".
Monday, October 09, 2006
Failure of Offshore job
10/7
Яамар ямар шалтгаанаар оффшоре ажлууд амжилтгүй болдог вэ?. гэсэн сэдэвээр бид пресентатион тавив. Үүнийг гаргахын тулд Fishbone болон KJ аргуудыг хэрэглэв. Эдгээр нь их энгийн хэрнээ үр дүн нь их ойлгомжтой байсан юм. Энэ аргуудын талаас Саруул дараа бичнэ.
Төсөл яагаад амжилтгүй болдог вэ?.
Энэ нь үндсэндээ 4 үндсэн шалтгаанаас болж оффшоре төсөл амжилтгүй болох нөхцөл бүрддэг. Үүнд голлох үүрэгтэй оролцож байгаа 3 тал буюу Захиалагч, Гүйцэтгэгч, Гүүр Инженеер 3 ба бусад нөхцөлүүд гэж тодорхойлсон бөгөөд. Үүний дараа багийн бүх гишүүд яагаад оффшоор төсөл амжилтгүй болоод байгаа талаар дор бүрнээ 8 аас 10-н шалтгаан олж нэг нэг цаасан дээр бичив. Дараа нь тэр цаасаа дээрх 4 ангилалдаа ангилаад ерөнхийд доорхи байдалаар нэгдгэсэн болно.
1. Захиалагч-аас хамаарч амжилтгүй болох хамгийн чухал гэж үзсэн нөхцөлүүд. (Customer)
Буруу муу гүйцэтгэгч сонвол (Give the job to a wrong vendor)
Хэрвээ үйлчилүүлэлч буруу гүйцэтгэгч буюу огт туршилгагүй шинэ компанид маш том ажил өгсөн тохиолдолд оффшоор ажил амжилтгүй болох нь ойлгомжтой.
Гүүр систем инженеертэй харилцаа муу байвал (Poor communication with BSE)
Энэ нь гүүр систем инжинээртэй харилцахдаа холбоо харилцаа нь маш муу байвал буюу захиалагч компани идвэхгүй байгаад байвал энэ оффшоор ажил амжилтгүй болох болно.
Тохиромжгүй үнэ (Unrealized Cost)
Захиалагч компани хийлгэх ажилдаа өгөх үнэ нь хэт бага тохиромжгүй байвал энэ оффшоор ажил амжилтгүй болох болно.
Үндсэн дезайны алдаа (Basic Design Mistake)
Зарим тохиолдолд захиалагч компанын шаардлага дээр үндэслэн гаргадаг үндсэн дезайний бичиг баримтыг захиалагч компаний өөрөө хийх тохиолдол байдаг. Энэ баримт бичиг нь алдаатай буруу байх юм бол мөн оффшоор төсөл амжилгүй болох хүчин зүйл болно.
Хэт их өөрчилөлтүүд эсвэл хэт том өөрчилөлт (Too many change requests)
Захиалагч тал анх өгсөн шаардлага аа хэт их өөрчилөөд байвал. Энэ нь анх захиалагчийн өгсөн шаардлагийг үндэслэн маш их ажил хийгдсэн хойно нь үндсэн шаардлагыг нь захиалагч тал өөрчилөөд байх юм бол энэ нь анх төлөвлөсөн хугацаандаа амжилгүй байдалд хүрдэг. Энэ бас оффшоор төсөл амжилтгүй болох үндэс болно.
Хамрах бага тодорхойлвол (Scope Creep)
Төслийн хамрах хүрээг маш бага дутуу тодорхойлож өгөх юм бол энэ нь мөн л оффшоор төсөл амжилтгүй болох шалтгааны үндэс нь болох болно.
Мөнгөгүй (No money)
Захиалагч тал нь хийлгэх ажлынхаа хөлсийг төлж дийлэхгүй байж ажил хийлгэж эхлэх юм бол энэ оффшоор төсөл ажилтгүй болох нь ойлгомжтой.
2. Гүйцэтгэгч талаас хамаарах хүчин зүйлүүд
Төслөө сайн удирдаж чадахгүй (Project are not well controlled)
Төслөө сайн удирдаж чадахгүй бол. Энэ нь маш их эмх замбараагүй ажилууд нь давхар давхах хийгдээд байвал энэ оффшоор төсөл амжилттай болж чадахгүй.
Ур чадвар болон Туршилга бага ( Poor in IT Skills and Exp)
Гүйцэтгэгч тал нь ямар ч ажил гүйцэтгэж байсан туршилгагүй эсвэл ажилчидынх нь ур чадвар нь бага бол ажилын чанар болон үр дүн нь муу гарна. Үр дүн нь муу чанаргүй бол тухайн оффшоор төсөл амжилтгүй болсон гэсэн үг.
Соёлын ялгааны алдаа ( Error for different cultures )
Оффшоор ажил дээр гардаг нийтдлэг асуудал бол соёлын ялгаа юм. Хамгийн энгийн жишээ гэрэд Японоос оффшоор ажил авч хийж байгаа тохиолдолд Ханз болон крилл үсгийн ялгаа, Encoding ийн ялгаа. гэх мэт бага гэж хэлэж болохуйц зүйлүүдийг анзаарч засаж байхгүй бол үүнээс болж оффшоор төсөл маань амжилтгүй болох магадлал өндөр байна.
IT ийн мэдлэгийн зөрүү ( Error for different IT Tech )
Энэ нь тухайн захиалагч тал нь өмнө нь иймэрхүү оффшоор ажилууд хийлгэж байсан ариун туршилгатай компани бол бүх л бичиг баримтуудаа өөрсдийн гэсэн загварт оруулан бичиг баримтийг хийлгэхийг шаардах тохиолдолд бүх л бичиг баримтаа захиалагчийн шаардлагад нийцүүлэн хийх хэрэг гарна. Хэрвээ үүнийг нь урьдчилан мэдээгүй өөрсдийнхөө загвараар хийчихсэн тохиолдолд энэ бичиг баримтийн ажлыг 2 удаа хийх хэрэгтэй болно.
Гүүр систем инженеертэйгээ харилцаа муу ( Poor communication with BSE )
Оффшоор ажлыг гүйцэтгэж байгаа компани тухайн ажилд томилогдсон гүүр систем инженеертэйгээ харилцаа холбоо сайн биш бол 2 талд өөр өөр ойлголтууд үүсэж оффшоор ажил буруу болох магадлалтай.
Төслийн нууцлал алдагдвал ( Failure in Data Security)
Төслийн нуулал муу нууц материалууд алдагдвал төсөл нурахаас гадна. Тухайн компани болон захиалагч компани маш том хорирол амсдаг учираас энэ нууцлалын асуудал маш чухалд тооцогдоно.
3. Гүүр инженеерээс хамаарах хүчин зүйлүүд. ( Bridge SE )
Харилцаа муу ( Poor Communication )
Гүүр инженеер хүн маань хүнтэй харилцахдаа муу янз бүрийн багажуудыг ашиглаж чаддаггүй бол. Тухайн төсөл дээр ажиллаж байгаа 2 талийг багууд ойлголцож чадахгүйд хүрнэ.
Буруу орчуулага ( Wrong Translation )
Энэ бол маш том эрсдэл. Гүүр инженеер хүн маань маш хариуцлагатай чухал үүрэг хүлээсэн хүн хэрвээ орчуулага дээрээ ямар нэг утгын зөрүүтэй орчуулга хийвэл. Оффшоор ажил хийж байгаа 2 талийн ойлголт зөрнө. Ойлголт зөрүүтэй байгааг эрт засаж чадахгүй бол оффшоор төсөл амжилтгүй болох магадлал маш өндөр болно.
Бизнессын мэдлэггүй ( Loss of Business Knowledge )
Гүүр инженеер хүн тухайн харилцаж байгаа гадны улсын компанийн бизнессийн соёлийг маш сайн мэдэхгүй, тухайн компанийн дээд албан тушаалтануудыг сайн хүндэтгэж мэдэхгүй бол тухайн тэр хүнд итгэж ямар нэг ажил өгөхгүйд хүрнэ.
Ёс заншилийн мэдлэггүй ( Loss of Culture Knowledge)
Тухайн улсынхаа ёсзаншил өвөрмөц соёлуудыг нь зайлшгүй мэдэж байх хэрэгтэй. Үүнийг мэдэхгүй эсвэл мэдсэн ч өөрийн багийнхандаа тайлбарлаж байхгүй бол эрсдэлтэй. Жишээ нь. Ямар нэг вэбийг загвар гаргаж байя гэж саная. Манайхан бол Япончууд өндөр соёлтой улсууд юм чинь хачин чамин загварт дуртай байх гэж таагаад л хамаг цагаа дезайн дээр бараж бараж сүүлд нь үзүүлсэн чинь нөгөөдүүл нь барууныхны загвараар хийсэн зүйлд дургүй өөрсдийн маш энгийн болхи ч гэх хэлэж болохоор загваруудыг шаардана. Хэдийгээр амжилтгүй болох магадлал нь бага ч гэсэн маш их хүч хөдөлмөрөө дэмий зүйлд зарцуулана.
Үхрийн сүүлэн дээр хутга ( Deliver Failure )
Оффшоор төсөл маань дуусаад 90 хувийг нь хийчихлээ гэж үзэж байтал. Сүүлд нь жижиг жижиг засвар өөрчлөлтүүд маш их ирдэг. Үүнийг тооцолгүй дуусчихлаа гэж таавшираад өөр ажил эхлэх үед өөрчлөлтүүд нь жинхэн ирэж эхэлдэг. Үүнийг нь тооцож төсөл хооронд 7 оос 14 хоног орчимын зайтай ажилуудаа төлөвлөхгүй бол 2 ажил давхардаж хийгдэх аль нэгийг нь сонгож fail болгох хэрэгтэй болож магадгүй.
4. Бусад хүчин зүйлүүд ( Other )
Осолууд ( Disasters )
Оффшоор төсөл хэгжиж байх үед ямар нэг осол болж аль нэг компани нь түүнд өртвөл төсөл амжилтгүй болох магадлалтай.
Ажилаас халагдах ( Resign Staff )
Оффшоор төсөл хэрэгжиж байх үед голлох үүрэгтэй ажиллаж байгаа ажилчин нь ажилаас, халагдах урт хугацааны амралт авах гэх мэт шалтгаануудаас болож ажилд оролцохоо болих үед төсөл амжилтгүй болох магадлалтай.
Хуулийн заалтууд ( Policy Reasons )
Оффшоор ажилд хийгдэсэн янз бүрийн үйл ажиллагаанууд нь 2 улсын хуулийг заалт зөгчсөн зүйлүүд тусгагдсан бол оффшоор төсөл амжилтгүй болно.
Дамжуулалтын алдаанууд ( Transfer Errors )
Оффшоор төслийн үед 2 талууд ихэвчилэн майлаар гол гол мэдээлэлүүдээ солилцох нь элбэг. Тиймээс майл сервэр нь маш найдвартай ажиллагаатай байхгүй бол чухал чухал майлууд дамжилгүй замдаа устгагдсан тохиолдолд төслийн биелэлтэнд нөлөөлөх магадлалтай.
Цагийн бүс ( Time Zone )
Харилцан ажиллаж байгаа 2 улс маань цагийн бүсийн зөрүүтэй бол цагийн бүсийн тооцож ажиллаж байх хэрэгтэй.
Эцэст нь
Дээрх зүйлсууд нь энэ сургалтанд ирсэн манай багийн хүмүүсийн ярилцаж байгаад гаргасан хүчин зүйлүүд болхоор буруу дутуу зүйлүүд байж магадгүй. Үүнтэй хамааралтай янз бүрийн тэмдэглэл хичээлүүд байдаг. Гүүглэ ээс "Failure of Offshore job" түлхүүр үгээр хайхад зөндөө зүйлүүд гарч ирнэ. Дээр яригдсан асуудалуудыг нэгтгээд доорхи зурагт нэгтгэн үзүүлэв.
Яамар ямар шалтгаанаар оффшоре ажлууд амжилтгүй болдог вэ?. гэсэн сэдэвээр бид пресентатион тавив. Үүнийг гаргахын тулд Fishbone болон KJ аргуудыг хэрэглэв. Эдгээр нь их энгийн хэрнээ үр дүн нь их ойлгомжтой байсан юм. Энэ аргуудын талаас Саруул дараа бичнэ.
Төсөл яагаад амжилтгүй болдог вэ?.
Энэ нь үндсэндээ 4 үндсэн шалтгаанаас болж оффшоре төсөл амжилтгүй болох нөхцөл бүрддэг. Үүнд голлох үүрэгтэй оролцож байгаа 3 тал буюу Захиалагч, Гүйцэтгэгч, Гүүр Инженеер 3 ба бусад нөхцөлүүд гэж тодорхойлсон бөгөөд. Үүний дараа багийн бүх гишүүд яагаад оффшоор төсөл амжилтгүй болоод байгаа талаар дор бүрнээ 8 аас 10-н шалтгаан олж нэг нэг цаасан дээр бичив. Дараа нь тэр цаасаа дээрх 4 ангилалдаа ангилаад ерөнхийд доорхи байдалаар нэгдгэсэн болно.
1. Захиалагч-аас хамаарч амжилтгүй болох хамгийн чухал гэж үзсэн нөхцөлүүд. (Customer)
Буруу муу гүйцэтгэгч сонвол (Give the job to a wrong vendor)
Хэрвээ үйлчилүүлэлч буруу гүйцэтгэгч буюу огт туршилгагүй шинэ компанид маш том ажил өгсөн тохиолдолд оффшоор ажил амжилтгүй болох нь ойлгомжтой.
Гүүр систем инженеертэй харилцаа муу байвал (Poor communication with BSE)
Энэ нь гүүр систем инжинээртэй харилцахдаа холбоо харилцаа нь маш муу байвал буюу захиалагч компани идвэхгүй байгаад байвал энэ оффшоор ажил амжилтгүй болох болно.
Тохиромжгүй үнэ (Unrealized Cost)
Захиалагч компани хийлгэх ажилдаа өгөх үнэ нь хэт бага тохиромжгүй байвал энэ оффшоор ажил амжилтгүй болох болно.
Үндсэн дезайны алдаа (Basic Design Mistake)
Зарим тохиолдолд захиалагч компанын шаардлага дээр үндэслэн гаргадаг үндсэн дезайний бичиг баримтыг захиалагч компаний өөрөө хийх тохиолдол байдаг. Энэ баримт бичиг нь алдаатай буруу байх юм бол мөн оффшоор төсөл амжилгүй болох хүчин зүйл болно.
Хэт их өөрчилөлтүүд эсвэл хэт том өөрчилөлт (Too many change requests)
Захиалагч тал анх өгсөн шаардлага аа хэт их өөрчилөөд байвал. Энэ нь анх захиалагчийн өгсөн шаардлагийг үндэслэн маш их ажил хийгдсэн хойно нь үндсэн шаардлагыг нь захиалагч тал өөрчилөөд байх юм бол энэ нь анх төлөвлөсөн хугацаандаа амжилгүй байдалд хүрдэг. Энэ бас оффшоор төсөл амжилтгүй болох үндэс болно.
Хамрах бага тодорхойлвол (Scope Creep)
Төслийн хамрах хүрээг маш бага дутуу тодорхойлож өгөх юм бол энэ нь мөн л оффшоор төсөл амжилтгүй болох шалтгааны үндэс нь болох болно.
Мөнгөгүй (No money)
Захиалагч тал нь хийлгэх ажлынхаа хөлсийг төлж дийлэхгүй байж ажил хийлгэж эхлэх юм бол энэ оффшоор төсөл ажилтгүй болох нь ойлгомжтой.
2. Гүйцэтгэгч талаас хамаарах хүчин зүйлүүд
Төслөө сайн удирдаж чадахгүй (Project are not well controlled)
Төслөө сайн удирдаж чадахгүй бол. Энэ нь маш их эмх замбараагүй ажилууд нь давхар давхах хийгдээд байвал энэ оффшоор төсөл амжилттай болж чадахгүй.
Ур чадвар болон Туршилга бага ( Poor in IT Skills and Exp)
Гүйцэтгэгч тал нь ямар ч ажил гүйцэтгэж байсан туршилгагүй эсвэл ажилчидынх нь ур чадвар нь бага бол ажилын чанар болон үр дүн нь муу гарна. Үр дүн нь муу чанаргүй бол тухайн оффшоор төсөл амжилтгүй болсон гэсэн үг.
Соёлын ялгааны алдаа ( Error for different cultures )
Оффшоор ажил дээр гардаг нийтдлэг асуудал бол соёлын ялгаа юм. Хамгийн энгийн жишээ гэрэд Японоос оффшоор ажил авч хийж байгаа тохиолдолд Ханз болон крилл үсгийн ялгаа, Encoding ийн ялгаа. гэх мэт бага гэж хэлэж болохуйц зүйлүүдийг анзаарч засаж байхгүй бол үүнээс болж оффшоор төсөл маань амжилтгүй болох магадлал өндөр байна.
IT ийн мэдлэгийн зөрүү ( Error for different IT Tech )
Энэ нь тухайн захиалагч тал нь өмнө нь иймэрхүү оффшоор ажилууд хийлгэж байсан ариун туршилгатай компани бол бүх л бичиг баримтуудаа өөрсдийн гэсэн загварт оруулан бичиг баримтийг хийлгэхийг шаардах тохиолдолд бүх л бичиг баримтаа захиалагчийн шаардлагад нийцүүлэн хийх хэрэг гарна. Хэрвээ үүнийг нь урьдчилан мэдээгүй өөрсдийнхөө загвараар хийчихсэн тохиолдолд энэ бичиг баримтийн ажлыг 2 удаа хийх хэрэгтэй болно.
Гүүр систем инженеертэйгээ харилцаа муу ( Poor communication with BSE )
Оффшоор ажлыг гүйцэтгэж байгаа компани тухайн ажилд томилогдсон гүүр систем инженеертэйгээ харилцаа холбоо сайн биш бол 2 талд өөр өөр ойлголтууд үүсэж оффшоор ажил буруу болох магадлалтай.
Төслийн нууцлал алдагдвал ( Failure in Data Security)
Төслийн нуулал муу нууц материалууд алдагдвал төсөл нурахаас гадна. Тухайн компани болон захиалагч компани маш том хорирол амсдаг учираас энэ нууцлалын асуудал маш чухалд тооцогдоно.
3. Гүүр инженеерээс хамаарах хүчин зүйлүүд. ( Bridge SE )
Харилцаа муу ( Poor Communication )
Гүүр инженеер хүн маань хүнтэй харилцахдаа муу янз бүрийн багажуудыг ашиглаж чаддаггүй бол. Тухайн төсөл дээр ажиллаж байгаа 2 талийг багууд ойлголцож чадахгүйд хүрнэ.
Буруу орчуулага ( Wrong Translation )
Энэ бол маш том эрсдэл. Гүүр инженеер хүн маань маш хариуцлагатай чухал үүрэг хүлээсэн хүн хэрвээ орчуулага дээрээ ямар нэг утгын зөрүүтэй орчуулга хийвэл. Оффшоор ажил хийж байгаа 2 талийн ойлголт зөрнө. Ойлголт зөрүүтэй байгааг эрт засаж чадахгүй бол оффшоор төсөл амжилтгүй болох магадлал маш өндөр болно.
Бизнессын мэдлэггүй ( Loss of Business Knowledge )
Гүүр инженеер хүн тухайн харилцаж байгаа гадны улсын компанийн бизнессийн соёлийг маш сайн мэдэхгүй, тухайн компанийн дээд албан тушаалтануудыг сайн хүндэтгэж мэдэхгүй бол тухайн тэр хүнд итгэж ямар нэг ажил өгөхгүйд хүрнэ.
Ёс заншилийн мэдлэггүй ( Loss of Culture Knowledge)
Тухайн улсынхаа ёсзаншил өвөрмөц соёлуудыг нь зайлшгүй мэдэж байх хэрэгтэй. Үүнийг мэдэхгүй эсвэл мэдсэн ч өөрийн багийнхандаа тайлбарлаж байхгүй бол эрсдэлтэй. Жишээ нь. Ямар нэг вэбийг загвар гаргаж байя гэж саная. Манайхан бол Япончууд өндөр соёлтой улсууд юм чинь хачин чамин загварт дуртай байх гэж таагаад л хамаг цагаа дезайн дээр бараж бараж сүүлд нь үзүүлсэн чинь нөгөөдүүл нь барууныхны загвараар хийсэн зүйлд дургүй өөрсдийн маш энгийн болхи ч гэх хэлэж болохоор загваруудыг шаардана. Хэдийгээр амжилтгүй болох магадлал нь бага ч гэсэн маш их хүч хөдөлмөрөө дэмий зүйлд зарцуулана.
Үхрийн сүүлэн дээр хутга ( Deliver Failure )
Оффшоор төсөл маань дуусаад 90 хувийг нь хийчихлээ гэж үзэж байтал. Сүүлд нь жижиг жижиг засвар өөрчлөлтүүд маш их ирдэг. Үүнийг тооцолгүй дуусчихлаа гэж таавшираад өөр ажил эхлэх үед өөрчлөлтүүд нь жинхэн ирэж эхэлдэг. Үүнийг нь тооцож төсөл хооронд 7 оос 14 хоног орчимын зайтай ажилуудаа төлөвлөхгүй бол 2 ажил давхардаж хийгдэх аль нэгийг нь сонгож fail болгох хэрэгтэй болож магадгүй.
4. Бусад хүчин зүйлүүд ( Other )
Осолууд ( Disasters )
Оффшоор төсөл хэгжиж байх үед ямар нэг осол болж аль нэг компани нь түүнд өртвөл төсөл амжилтгүй болох магадлалтай.
Ажилаас халагдах ( Resign Staff )
Оффшоор төсөл хэрэгжиж байх үед голлох үүрэгтэй ажиллаж байгаа ажилчин нь ажилаас, халагдах урт хугацааны амралт авах гэх мэт шалтгаануудаас болож ажилд оролцохоо болих үед төсөл амжилтгүй болох магадлалтай.
Хуулийн заалтууд ( Policy Reasons )
Оффшоор ажилд хийгдэсэн янз бүрийн үйл ажиллагаанууд нь 2 улсын хуулийг заалт зөгчсөн зүйлүүд тусгагдсан бол оффшоор төсөл амжилтгүй болно.
Дамжуулалтын алдаанууд ( Transfer Errors )
Оффшоор төслийн үед 2 талууд ихэвчилэн майлаар гол гол мэдээлэлүүдээ солилцох нь элбэг. Тиймээс майл сервэр нь маш найдвартай ажиллагаатай байхгүй бол чухал чухал майлууд дамжилгүй замдаа устгагдсан тохиолдолд төслийн биелэлтэнд нөлөөлөх магадлалтай.
Цагийн бүс ( Time Zone )
Харилцан ажиллаж байгаа 2 улс маань цагийн бүсийн зөрүүтэй бол цагийн бүсийн тооцож ажиллаж байх хэрэгтэй.
Эцэст нь
Дээрх зүйлсууд нь энэ сургалтанд ирсэн манай багийн хүмүүсийн ярилцаж байгаад гаргасан хүчин зүйлүүд болхоор буруу дутуу зүйлүүд байж магадгүй. Үүнтэй хамааралтай янз бүрийн тэмдэглэл хичээлүүд байдаг. Гүүглэ ээс "Failure of Offshore job" түлхүүр үгээр хайхад зөндөө зүйлүүд гарч ирнэ. Дээр яригдсан асуудалуудыг нэгтгээд доорхи зурагт нэгтгэн үзүүлэв.
Friday, October 06, 2006
BSE Training course Эхний 7 хоног
CICC ээс зохион байгуулаж байгаа. Гүүр инженерийн сургалтанд сууж байгаа билээ. Энэ сургалтанд 10 суралцагч байгаа бөгөөд Монголоос 2, Хятадаас 2, Вьетнамаас 2, Мянмар гэдэг улсаас 4 суралцагч сурч байна.Энд зааж байгаа хичээлүүд нь.Эхний 7 хоног. Business JapaneseБизнесийн Япон хэл заасан бөгөөд тэр нь хөтөлбөр нь маш их шахуу байсан юм. Гэхдээ өмнө нь бага сага Япон хэл үзэж байсан маань их ойлгоход дөхөм болж байсан. Хичээлийн дундуур Токио хотоор явах даалгавар өгөв.
1. CICC дээр очиж Ямар нэг ажилтанаас нь тамга авах.
2. Акихибара дүүрэгт байдаг "Ёодобаши Камер" дэлгүүрээс 750 МБ ийн хэмжээтэй СД авахгэсэн 2 даалгавар өгч Токио хотоор баахан төөрүүлэв. хэхэ. Би ирээд дөнгөж 3 хонож байсан ийш тийшээ нь сайн явж мэдэхгүй баг болсон хүмүүсийгээ дагсаар байж ирсэн. Тэр үеээс аймаар их бороотой байсан болхоор гудманд хүнээс юм асуух хэцүү байв. Гэхдээ төөрсөөр байж олсоон.
1. CICC дээр очиж Ямар нэг ажилтанаас нь тамга авах.
2. Акихибара дүүрэгт байдаг "Ёодобаши Камер" дэлгүүрээс 750 МБ ийн хэмжээтэй СД авахгэсэн 2 даалгавар өгч Токио хотоор баахан төөрүүлэв. хэхэ. Би ирээд дөнгөж 3 хонож байсан ийш тийшээ нь сайн явж мэдэхгүй баг болсон хүмүүсийгээ дагсаар байж ирсэн. Тэр үеээс аймаар их бороотой байсан болхоор гудманд хүнээс юм асуух хэцүү байв. Гэхдээ төөрсөөр байж олсоон.
Subscribe to:
Posts (Atom)