Сайн уу? Намайг Андрей Семенов гэдэг, би Sportmaster-ийн ахлах шинжээч. Энэ нийтлэлд би ERP системийн мэдээллийн санг хэвийн бус болгох асуудлыг хөндөхийг хүсч байна. Бид ерөнхий нөхцөл, мөн тодорхой жишээг авч үзэх болно - энэ нь далайн дээрэмчид, далайчдын хувьд гайхалтай монополь зоогийн газар байх болно гэж бодъё. Далайн дээрэмчид, далайчдыг өөр өөрөөр үйлчлэх ёстой, учир нь эдгээр сайн ноёдын гоо үзэсгэлэн, хэрэглээний хэв маяг нь эрс ялгаатай байдаг.
Хүн бүрийг хэрхэн баярлуулах вэ? Ийм системийг зохион бүтээх, засвар үйлчилгээ хийх гэж галзуурахаас хэрхэн зайлсхийх вэ? Зөвхөн ердийн далайн дээрэмчид, далайчид таверанд ирж эхэлбэл яах вэ?
Бүх зүйл захын дор байна. Гэхдээ дарааллаар нь явцгаая.
1. Хязгаарлалт ба таамаглал
Дээрх бүх зүйл нь зөвхөн харилцааны мэдээллийн санд хамаарна. Интернэтийг оруулаад маш сайн тусгагдсан өөрчлөлт, устгах, оруулах гажиг хэлбэрийн хэвийн бус байдлын үр дагаврыг авч үзэхгүй. Энэхүү нийтлэлийн хамрах хүрээнээс гадуур хэвийн бус байдал нь ердийн зүйл болох тохиолдол байдаг бөгөөд сонгодог жишээнүүд: паспортын цуврал ба дугаар, огноо, цаг гэх мэт.
Энэхүү нийтлэлд математикийн нэр томьёог ишлэлгүйгээр энгийн хэлбэрүүдийн ойлгомжтой, практикт хэрэг болохуйц тодорхойлолтуудыг ашигласан болно. Бодит бизнесийн үйл явц (BP) болон үйлдвэрлэлийн програм хангамжийн дизайныг шалгахад тэдгээрийг ашиглаж болох хэлбэрээр.
Мэдээллийн агуулах, тайлагнах хэрэгсэл, нэгтгэх гэрээний загвар (мэдээллийг хүснэгт хэлбэрээр илэрхийлдэг) нь ERP системийн мэдээллийн баазын загвараас ялгаатай нь хэрэглээний хялбар байдал, үүнд хүрэхийн тулд ухамсартай хэвийн бус байдлыг ашиглах нь бүрэн бүтэн байдлаас дээгүүр байр суурь эзэлдэг гэж үздэг. хамгаалалтын өгөгдөл. Би энэ санал бодлыг хуваалцаж байгаа бөгөөд доор тайлбарласан зүйл нь зөвхөн ERP системийн үндсэн өгөгдөл болон гүйлгээний өгөгдлийн загварт хамаарна.
Энгийн хэлбэрийн тайлбарыг ихэнх уншигчдад өдөр тутмын түвшинд ойлгомжтой жишээ ашиглан өгсөн болно. Гэсэн хэдий ч 4-5-р догол мөрөнд харааны жишээ болгон зориудаар "зохиомол" даалгаврыг ашигласан болно. Хэрэв та үүнийг хийхгүй бөгөөд сурах бичгийн зарим жишээг, жишээлбэл, 2-р цэгээс ижил захиалгын хадгалалтын загварыг авбал уншигчдын анхаарлыг процессын санал болгож буй задралаас загвар болгон өөрчлөх нөхцөл байдалд орж болзошгүй. IS-д өгөгдөл хадгалах процесс, загварыг хэрхэн бүтээх талаар хувийн туршлага, ойлголт. Өөрөөр хэлбэл, хоёр мэргэшсэн мэдээллийн технологийн шинжээч авч, нэг нь зорчигч тээвэрлэж буй логистикчдод, нөгөө нь микрочип үйлдвэрлэх машин тээвэрлэдэг логистикчдод үйлчилгээ үзүүлээрэй. Автоматжуулсан АД-ыг урьдчилан хэлэлцэхгүйгээр тэднээс төмөр замын аяллын талаарх мэдээллийг хадгалах өгөгдлийн загварыг бий болгохыг хүс.
Санал болгож буй загваруудад та зөвхөн мэдэгдэхүйц ялгаатай шинж чанаруудыг төдийгүй өөр өөр объектуудыг олох магадлал XNUMX биш юм, учир нь шинжээч бүр өөрт нь танил болсон үйл явц, даалгаварт найдах болно. Ийм нөхцөлд ямар загвар "зөв" болохыг хэлэх боломжгүй, учир нь үнэлгээний шалгуур байхгүй.
2. Хэвийн хэлбэрүүд
Өгөгдлийн сангийн анхны ердийн хэлбэр бүх шинж чанаруудын атомыг шаарддаг.
Тодруулбал, хэрэв А объект нь c=f(a,b) гэсэн түлхүүр бус шинж чанаруудтай a ба b шинж чанаруудтай бөгөөд А объектыг тайлбарлах хүснэгтэд c шинж чанарын утгыг хадгалдаг бол мэдээллийн санд эхний хэвийн хэлбэрийг зөрчсөн болно. . Жишээлбэл, захиалгын тодорхойлолтод хэмжигдэхүүн нь бүтээгдэхүүний төрлөөс хамаардаг хэмжигдэхүүнийг зааж өгсөн бол: нэг тохиолдолд энэ нь ширхэг, өөр нэг литр, гурав дахь багцад хэсгүүдээс бүрдэх боломжтой (Good_count_WR дээрх загварт) , дараа нь өгөгдлийн санд шинж чанаруудын атомын байдал зөрчигддөг. Энэ тохиолдолд захиалгын тодорхойлолтын хүснэгтийн кластер ямар байх ёстойг хэлэхийн тулд IS дахь ажлын үйл явцын зорилтот тодорхойлолт хэрэгтэй бөгөөд процессууд нь өөр байж болох тул олон "зөв" хувилбар байж болно.
Мэдээллийн сангийн хоёр дахь ердийн хэлбэр IS дахь ажлын үйл явцтай холбоотой аж ахуйн нэгж бүрийн хувьд эхний маягт болон өөрийн хүснэгтийг дагаж мөрдөхийг шаарддаг. Хэрэв нэг хүснэгтэд c=f1(a) ба d=f2(b) хамаарал байгаа бөгөөд c=f3(b) хамаарал байхгүй бол хүснэгтэд хоёр дахь хэвийн хэлбэр зөрчигдсөн байна. Дээрх жишээнд Захиалгын хүснэгтэд захиалга, хаяг хоёрын хооронд хамаарал байхгүй. Гудамж эсвэл хотын нэрийг өөрчилснөөр та захиалгын үндсэн шинж чанаруудад ямар ч нөлөө үзүүлэхгүй.
Гурав дахь ердийн хэлбэрийн мэдээллийн сан Хоёрдахь хэвийн хэлбэрийг дагаж мөрдөх, янз бүрийн байгууллагуудын шинж чанаруудын хооронд функциональ хамаарал байхгүй байхыг шаарддаг. Энэ дүрмийг дараах байдлаар томъёолж болно: "Тооцоолж болох бүх зүйлийг тооцоолох ёстой." Өөрөөр хэлбэл, А ба В хоёр объект байгаа бол А объектын шинж чанаруудыг хадгалах хүснэгтэд C шинж чанар илэрч, В объект нь b шинж чанартай бөгөөд c=f4(b) байгаа бол гурав дахь хэвийн хэлбэр болно. зөрчигдөж байна. Доорх жишээн дээр захиалгын бүртгэл дээрх Хэмжээний тоо хэмжээ (Total_count_WR) нь гурав дахь хэвийн хэлбэрийг зөрчиж байгааг тодорхой харуулж байна.
3. Нормалчлалыг хэрэглэх миний хандлага
1. Зөвхөн зорилтот автоматжуулсан бизнесийн үйл явц нь өгөгдлийн хадгалалтын загвар үүсгэх үед аж ахуйн нэгж, шинж чанаруудыг тодорхойлох шалгуурыг шинжээчид өгч чадна. Процессын загварыг бий болгох нь ердийн өгөгдлийн загварыг бий болгох урьдчилсан нөхцөл юм.
2. Дараах нөхцлүүдийн заримыг эсвэл бүгдийг хангасан тохиолдолд ERP системийг бий болгох бодит практикт гуравдахь хэвийн хэлбэрт хүрэх нь бодит утгаар хэрэгжихгүй байж болно.
- автоматжуулсан процессууд өөрчлөгдөх нь ховор,
- судалгаа, хөгжүүлэлтийн эцсийн хугацаа хатуу,
- өгөгдлийн бүрэн бүтэн байдалд тавигдах шаардлагууд харьцангуй бага (үйлдвэрлэлийн програм хангамжид гарч болзошгүй алдаа нь програм хангамжийн үйлчлүүлэгчид мөнгө эсвэл үйлчлүүлэгчээ алдахад хүргэдэггүй)
- болон үүнтэй төстэй зүйлс.
Тодорхойлсон нөхцөлд зарим объектын амьдралын мөчлөг, тэдгээрийн шинж чанарыг тодорхойлох, тайлбарлах зардлыг эдийн засгийн үр ашгийн үүднээс зөвтгөж болохгүй.
3. Аль хэдийн үүсгэсэн IS-д өгөгдлийн загварыг хэвийн бус болгох аливаа үр дагаврыг кодыг сайтар судалж, туршилт хийснээр багасгаж болно.
4. Хөдөлмөрийн зардлыг өгөгдлийн эх сурвалжийг судлах, бизнесийн үйл явцыг төлөвлөх шатнаас хөгжлийн үе шат, хэрэгжүүлэх хугацаанаас систем боловсруулах үе хүртэл шилжүүлэх арга хэлбэрийг хэвийн бус болгох явдал юм.
5. Дараах тохиолдолд мэдээллийн сангийн гуравдахь хэвийн хэлбэрийг ашиглахыг хичээх нь зүйтэй.
- Автоматжуулсан бизнесийн үйл явцын өөрчлөлтийн чиглэлийг урьдчилан таамаглахад хэцүү байдаг
- Хэрэгжүүлэх ба/эсвэл боловсруулах багийн ажлын хуваарилалт сул байна
- Интеграцийн хэлхээнд багтсан системүүд нь өөрсдийн төлөвлөгөөний дагуу хөгждөг
- Мэдээллийн зөрчил нь компанид үйлчлүүлэгчид эсвэл мөнгөө алдахад хүргэдэг
6. Өгөгдлийн загварын дизайныг зөвхөн зорилтот бизнесийн үйл явцын загварууд болон IS дахь үйл явцтай уялдуулан шинжээч хийх ёстой. Хэрэв хөгжүүлэгч өгөгдлийн загвар зохион бүтээж байгаа бол тэрээр атомын шинж чанаруудыг тусгаарлах зайлшгүй нөхцөл болох шинж чанарын утгуудын хоорондын ялгааг ойлгохын тулд тухайн сэдвийн талбарт өөрийгөө шингээх шаардлагатай болно. Тиймээс ер бусын функцүүдийг авч байна.
4 Дүрслэх асуудал
Та боомтод жижиг робот ресторантай гэж бодъё. Таны зах зээлийн сегмент: боомтоор орж ирээд завсарлага авах шаардлагатай далайчид, далайн дээрэмчид. Та далайчдад гангатай цай, далайн дээрэмчдэд сахал самнах ром, ясны сам зардаг. Таверна дахь үйлчилгээг робот гэрийн эзэгтэй, робот бармен гүйцэтгэдэг. Таны өндөр чанар, хямд үнийн ачаар та өрсөлдөгчдөө хөөж, хөлөг онгоцноос бууж буй хүн бүр боомт дахь цорын ганц таверанд ирдэг.
Таверны мэдээллийн системийн цогцолбор нь дараахь програм хангамжаас бүрдэнэ.
- Онцлог шинж чанарт үндэслэн ангиллыг таньдаг үйлчлүүлэгчийн тухай эрт сэрэмжлүүлэх систем
- Робот гэрийн эзэгтэй, робот барменуудад зориулсан хяналтын систем
- Борлуулалтын цэг хүртэл агуулах, хүргэлтийн удирдлагын систем
- Нийлүүлэгчийн харилцааны удирдлагын систем (SURP)
Үйл явц:
Урьдчилан сэрэмжлүүлэх систем нь хөлөг онгоцыг орхиж буй хүмүүсийг танина. Хэрэв хүн цэвэрхэн хуссан бол түүнийг далайчин, сахалтай нь тогтоогдвол далайн дээрэмчин гэж тодорхойлдог.
Таверанд ороход зочин робот гэрийн эзэгтэйн ангиллын дагуу мэндчилгээг сонсдог, жишээлбэл: "Хо-хо-хо, эрхэм далайн дээрэмчин, №XNUMX ширээ рүү яв..."
Зочин заасан ширээнд очдог бөгөөд робот бармен түүнд ангиллын дагуу бараа бэлдсэн байдаг. Робот бармен нь хүргэлтийн дараагийн хэсгийг нэмэгдүүлэх шаардлагатай гэсэн мэдээллийг агуулахын системд дамжуулдаг; агуулах нь хадгалалтын үлдэгдэлд үндэслэн удирдлагын системд худалдан авах хүсэлтийг үүсгэдэг.
Урьдчилан сэрэмжлүүлэх системийг таны дотоод мэдээллийн технологи боловсруулсан байж болох ч бар роботын удирдлагын программыг гадны гэрээлэгч таны бизнест тусгайлан зориулж бүтээсэн байж магадгүй. Мөн агуулахыг удирдах систем, ханган нийлүүлэгчидтэй харилцах харилцаа нь зах зээлээс тохируулсан багц шийдэл юм.
5. Хэвийн өөрчлөлт, түүний програм хангамжийн хөгжилд үзүүлэх нөлөөллийн жишээ
Бизнесийн үйл явцыг зохион бүтээхдээ дэлхийн далайн дээрэмчид ром ууж, сахлаа ясны самаар самнадаг, далайчид гангатай цай ууж, үргэлж цэвэрхэн хусдаг гэж санал нэгтэй хэлжээ.
Үйлчлүүлэгчийн төрлүүдийн лавлах нь хоёр утгатай гарч ирнэ: 1 - далайн дээрэмчид, 2 - далайчид, компанийн бүх мэдээллийн хэлхээнд нийтлэг байдаг.
Үйлчлүүлэгчийн мэдэгдлийн систем нь зураг боловсруулах үр дүнг хүлээн зөвшөөрөгдсөн үйлчлүүлэгчийн танигч (ID) болон түүний төрөл болох далайчин эсвэл далайн дээрэмчин болгон нэн даруй хадгалдаг.
Хүлээн зөвшөөрөгдсөн объектын ID
Үйлчлүүлэгчийн ангилал
100500
Дээрэмчин
100501
Дээрэмчин
100502
Далайчин
Үүнийг дахин нэг удаа тэмдэглэе
1. Манай далайчид үнэндээ хуссан хүмүүс
2. Манай далайн дээрэмчид үнэндээ сахалтай хүмүүс
Манай бүтэц гурав дахь хэвийн хэлбэрт хүрэхийн тулд энэ тохиолдолд ямар бэрхшээлийг арилгах шаардлагатай байна:
- шинж чанарын атомын зөрчил - Үйлчлүүлэгчийн ангилал
- дүн шинжилгээ хийсэн баримт, дүгнэлтийг нэг хүснэгтэд нэгтгэх
- янз бүрийн аж ахуйн нэгжийн шинж чанаруудын хоорондын тогтмол функциональ харилцаа.
Хэвийн хэлбэрээр бид хоёр хүснэгт авах болно:
- тогтоосон шинж чанаруудын багц хэлбэрээр хүлээн зөвшөөрөх үр дүн;
Хүлээн зөвшөөрөгдсөн объектын ID
Нүүрний үс
100500
Тийм
100501
Тийм
100502
Ямар ч
- Тогтоосон шинж чанарыг тайлбарлах IS-д суулгасан логикийн хэрэглээ болгон үйлчлүүлэгчийн төрлийг тодорхойлсон үр дүн
Хүлээн зөвшөөрөгдсөн объектын ID
Таних ID
Үйлчлүүлэгчийн ангилал
100500
100001
Дээрэмчин
100501
100002
Дээрэмчин
100502
100003
Далайчин
Хэвийн өгөгдөл хадгалах байгууллага нь IP цогцолборыг хөгжүүлэхэд хэрхэн туслах вэ? Та гэнэт шинэ үйлчлүүлэгчтэй болсон гэж бодъё. Сахалгүй мөртлөө мөрөн дээрээ тоть барьдаг Японы далайн дээрэмчид, байгаль хамгаалагч далайн дээрэмчид бол Гретагийн зүүн цээжин дээрх цэнхэр дүрсээр тэднийг амархан таньж болно.
Байгаль орчны далайн дээрэмчид ясны сам ашиглах боломжгүй бөгөөд дахин боловсруулсан далайн хуванцараар хийсэн аналогийг шаарддаг.
Та шинэ оролтын дагуу програмын алгоритмуудыг дахин боловсруулах хэрэгтэй. Хэрэв хэвийн болгох дүрмийг дагаж мөрдвөл та зөвхөн зарим систем дэх процессын зарим салбаруудын оролтыг нөхөж, зөвхөн нүүрний үсний асуудал чухал тохиолдол болон IS-д шинэ салбаруудыг үүсгэх хэрэгтэй болно. Гэхдээ дүрмийг дагаж мөрдөөгүй тул үйлчлүүлэгчийн төрлийн лавлах утгуудыг ашигладаг бүхэл бүтэн хэлхээний кодыг бүхэлд нь задлан шинжилж, нэг тохиолдолд алгоритм нь мэргэжлийн хүмүүсийг харгалзан үзэх ёстойг тодорхой тогтоох шаардлагатай болно. Үйлчлүүлэгчийн үйл ажиллагаа болон бусад физик шинж чанарууд.
Ийм хэлбэрээр хайж байна хэвийн болгохын тулд бид үйлдлийн өгөгдөл, хоёр лавлах бүхий хоёр хүснэгтийг авах болно:
- тогтоосон шинж чанаруудын багц хэлбэрээр хүлээн зөвшөөрөх үр дүн;
Хүлээн зөвшөөрөгдсөн объектын ID
Грета зүүн цээжинд
Мөрөн дээрх шувуу
Нүүрний үс
100510
1
1
1
100511
0
0
1
100512
1
0
- үйлчлүүлэгчийн төрлийг тодорхойлох үр дүн (энэ нь лавлахуудын тайлбарыг харуулдаг захиалгат харагдац байх болтугай)
Илэрсэн хэвийн бус байдал нь системийг шинэ нөхцөлд тохируулан өөрчлөх боломжгүй гэсэн үг үү? Мэдээж үгүй. Хэрэв бид бүх мэдээллийн системийг нэг баг бүрдүүлсэн, боловсон хүчний халаа сэлгээ байхгүй, бүтээн байгуулалтыг сайтар баримтжуулж, мэдээллийг баг дотор алдалгүй дамжуулдаг гэж төсөөлвөл шаардлагатай өөрчлөлтийг өчүүхэн бага хүчин чармайлтаар хийж болно. Гэхдээ бид асуудлын анхны нөхцөл рүү буцвал хамтарсан хэлэлцүүлгийн протоколыг хэвлэхийн тулд 1,5 гар, худалдан авалтын журмыг боловсруулахад зориулж өөр 0,5 гар арилах болно.
Дээрх жишээнд гурван хэвийн хэлбэр бүгд зөрчигдсөн тул тусад нь зөрчихийг оролдъё.
Эхний хэвийн хэлбэрийг зөрчих:
Таны агуулахад нийлүүлэгчдийн агуулахаас барааг танай ресторанд харьяалагддаг 1.5 тоннын даацтай нэг цагаан зээрээр ачиж авчирдаг гэж бодъё. Таны захиалгын хэмжээ нь ханган нийлүүлэгчдийн бараа эргэлттэй харьцуулахад маш бага тул үйлдвэрлэлийг хүлээхгүйгээр үргэлж нэг нэгээр нь гүйцэтгэнэ. Танд ийм бизнесийн үйл явцтай тусдаа хүснэгт хэрэгтэй байна уу: тээврийн хэрэгсэл, тээврийн хэрэгслийн төрөл, явсан ханган нийлүүлэгчдэд захиалга өгөхдөө төлөвлөгөө, баримтыг салгах шаардлагатай юу?
Хэрэв та доорх загварыг программ боловсруулахдаа ашиглавал таны програмистууд хичнээн "нэмэлт" холболт бичих шаардлагатай болохыг төсөөлөөд үз дээ.
Санал болгож буй бүтэц нь шаардлагагүй төвөгтэй гэж бид шийдсэн гэж бодъё; манай тохиолдолд захиалгын бүртгэл дэх төлөвлөгөө, баримтыг салгах нь илүүдэл мэдээлэл бөгөөд үүссэн захиалгын тодорхойлолтыг ирсэн барааг хүлээн авсан үр дүнд үндэслэн дахин бичсэн болно. -Зэрэглэл, чанар муутай барааг IS-ээс гадуур шийдвэрлэсэн.
Тэгээд нэг өдөр та таверны танхим бүхэлдээ ууртай, эмх замбараагүй далайн дээрэмчдээр дүүрч байгааг харах болно. Юу болсон бэ?
Таны бизнес өсөхийн хэрээр таны хэрэглээ ч өссөн байна. Нэгэн удаа зээрд хэт их ачаалалтай буюу нэн ховор тохиолдсон зээрийн ачааллыг ханган нийлүүлэгч нь ундны ач тусыг илүүд үздэг гэсэн удирдлагын шийдвэр гарсан.
Хүргэгдээгүй бараа дараагийн дарааллаар дуусч, шинэ нислэгээр явав; Таверна дахь агуулахад хамгийн бага үлдэгдэл байгаа нь алга болсон тохиолдлыг анзаарахгүй байх боломжийг олгосон.
Сүүлчийн өрсөлдөгч боомт дээр хаагдаж, тээврийн хэрэгслийн хамгийн бага балансын хүрэлцээ, үе үе дутуу ачааллыг тооцсоны үндсэн дээр эрэмбэлэх замаар давсан зээрийн хэт ачааллын цоорсон тохиолдол түгээмэл болсон. Бүтээсэн систем нь түүнд суулгасан алгоритмын дагуу ажиллахад тохиромжтой бөгөөд төлөвлөсөн захиалгыг биелүүлээгүйг хянах ямар ч боломжоос хасагдах болно. Гэмтсэн нэр хүнд, сэтгэл ханамжгүй үйлчлүүлэгчид л асуудлыг илрүүлэх боломжтой болно.
Анхааралтай уншигч 2 болон 5-р хэсэг дэх захиалгын тодорхойлолтод (T_ORDER_SPEC) заасан хэмжээ нь эхний ердийн маягтын шаардлагад нийцэж эсвэл тохирохгүй байгааг анзаарсан байх. Сонгосон барааны нэр төрлийг харгалзан өөр өөр хэмжүүрүүд нэг талбарт хамаарах эсэхээс бүх зүйл хамаарна.
Хоёр дахь хэвийн хэлбэрийг зөрчих:
Таны хэрэгцээ өсөхийн хэрээр та өөр өөр хэмжээтэй хэд хэдэн машин худалдаж авдаг. Дээрх нөхцөл байдалд тээврийн хэрэгслийн лавлах үүсгэх нь шаардлагагүй гэж үзсэн тул хүргэлт, агуулахын хэрэгцээнд нийцсэн бүх өгөгдөл боловсруулах алгоритмууд ханган нийлүүлэгчээс агуулах хүртэлх ачааны хөдөлгөөнийг зөвхөн 1,5 тоннын нислэг гэж үздэг. цагаан зээр. Тиймээс, шинэ тээврийн хэрэгсэл худалдаж авахын зэрэгцээ та тээврийн хэрэгслийн лавлах үүсгэсэн хэвээр байгаа боловч үүнийг эцэслэн боловсруулахдаа тухайн газар бүрт шинж чанаруудтай холбоотой лавлагаа байгаа эсэхийг олж мэдэхийн тулд ачааны хөдөлгөөнд хамаарах бүх кодыг шинжлэх шаардлагатай болно. бизнес эхэлсэн тээврийн хэрэгслийн тухай.
Гурав дахь хэвийн хэлбэрийг зөрчих:
Хэзээ нэгэн цагт та үнэнч үйлчилгээний хөтөлбөр үүсгэж эхлэхэд байнгын үйлчлүүлэгчийн бүртгэл гарч ирнэ. Жишээлбэл, үнэнч байх хөтөлбөрийн эхэнд үйлчлүүлэгчийн сонирхсон бүх зүйлийг үйлчлүүлэгчийн бүртгэлд байршуулж болох юм бол тайлагнах, аналитик системд шилжүүлэхэд ашиглахын тулд хувь хүний хувьд борлуулалтын нэгдсэн өгөгдлийг хадгалах материаллаг үзэл бодлыг бий болгоход яагаад цаг зарцуулдаг вэ? ? Тэгээд үнэхээр эхлээд харахад ямар ч утгагүй юм. Гэхдээ таны бизнес, жишээлбэл, борлуулалтын шинэ сувгуудыг холбох бүрт таны шинжээчдийн дунд ийм нэгтгэх шинж чанар байдгийг санах хүн байх ёстой.
Шинэ үйл явц бүрийг төлөвлөхдөө, жишээлбэл, Интернет дэх борлуулалт, нийтлэг үнэнч байдлын системд холбогдсон дистрибьютерээр дамжуулан борлуулах гэх мэт бүх шинэ процессууд нь кодын түвшинд мэдээллийн бүрэн бүтэн байдлыг хангах ёстой гэдгийг хэн нэгэн санаж байх ёстой. Мянган хүснэгт бүхий аж үйлдвэрийн мэдээллийн сангийн хувьд энэ нь боломжгүй ажил мэт санагдаж байна.
Туршлагатай хөгжүүлэгч мэдээжийн хэрэг дээр дурдсан бүх асуудлыг хэрхэн зогсоохыг мэддэг, гэхдээ миний бодлоор туршлагатай шинжээчийн үүрэг бол тэдгээрийг ил гаргах явдал биш юм.
Нийтлэлийг бэлтгэх явцад үнэтэй санал хүсэлтээ өгсөн тэргүүлэгч хөгжүүлэгч Евгений Ярухинд би талархлаа илэрхийлье.
Уран зохиол
Коннолли Томас, Бегг Каролин. Өгөгдлийн сан. Зураг төсөл, хэрэгжилт, дэмжлэг. Онол ба практик
Эх сурвалж: www.habr.com