تغییر مهندسی دیر به خرید می‌رسد
Spec عوض می‌شود و ماه‌ها بعد، در PO یا هنگام Delivery مشخص می‌شود که چیز دیگری خریده شده است.
ERP یکپارچهٔ مهندسی، خرید و کنترل پروژه
پروژه‌های بزرگ،
پروژه‌های بزرگ،
با دقتِ کولیس
اداره می‌شوند.
از نقشه و مدرک تا خرید، ساخت و کنترل پروژه؛ همه روی یک هستهٔ داده. هر عدد منبعش را دارد، هر تغییر Impact آن را نشان می‌دهد و هر تأخیر پیش از آنکه دیر شود دیده می‌شود.
- ۴ حوزه · ۱۴ ماژول یکپارچه
- استقرار روی سرور شما
- ورودی PDF / DWG
Progress کل68.4%+1.2 این ماه
SPI0.97شاخص Schedule
CPI0.98شاخص هزینه
PO226از ۲۶۸ RFQ
S-Curve
- Plan
- Actual
- Forecast
Alerts
4 EVENTS- P-101Aتأخیر Delivery ۱۴ روز؛ Activity ACT-214 بحرانی شد
- V-101تغییر Spec؛ ۲ RFQ و ۱ PO Impacted
- TBE-041ارزیابی کامل شد؛ توصیهٔ خرید آماده است
- DS-101رویژن B تهیه و برای وندورها ارسال شد
دادهٔ نمونه و ساختگی؛ نه پروژهٔ واقعی مشتری.
INPUTPDFDWGPROJECT KNOWLEDGE GRAPHLine ListRFQ · TBE · POExpeditingS-CurveCost · RiskOUTPUT
مسئلهمهندسی، خرید و Schedule
مهندسی، خرید و Schedule
سه جزیره‌اند.
۳ تا ۵ هزارنقشهٔ P&ID در یک پروژهٔ بزرگ؛ و هر تغییر در یکی، باید به مدارک، POها و Schedule برسد.
Progress یعنی برداشتِ شخصی
درصد Progress بدون معیار وزن‌دهی و Evidence پذیرش، گزارش است، نه اندازه‌گیری.
تأخیر وندور دیر دیده می‌شود
Delivery یک Equipment کلیدی به‌تعویق می‌افتد و Impact آن روی Critical Path وقتی معلوم می‌شود که کار از کار گذشته است.
پلتفرمیک هسته، چهار حوزه،
یک هسته، چهار حوزه،
یک ERP کامل مهندسی.
کولیس فقط یک ابزار نیست؛ یک ERP تخصصی پروژه‌های مهندسی است. مهندسی، مدارک، خرید و کنترل پروژه روی یک هستهٔ داده کار می‌کنند و هر ماژول، دادهٔ دیگری را بی‌واسطه می‌بیند.
CORE
هستهٔ داده
۱۴ماژولیک هویت برای هر Equipment، خط، مدرک و PO؛ هر ماژول از همین هسته می‌خواند و به آن می‌افزاید.
مهندسی و داده‌های فنی
- Cortexخواندن و شناسایی اجزای نقشه، با منبع هر مشاهده
- ExploreKnowledge Graph پروژه؛ جستوجو و پیمایش ارتباطها
- BasisDesign Basis نسخه‌دار
- CalcLabمحاسبات متصل به Basis
- MatPlanمواد و MTO؛ پل مهندسی به خرید
Document Control
خرید و تأمین
- VendorHubوندورها، Qualification و مدارک وندور
- BidWiseRFQ، TBE، توصیهٔ خرید
- OrderFlowPO، Expediting، Inspection و Delivery
Planning و کنترل پروژه
- PlanCraftSchedule، Critical Path و Baseline
- WorkSightEvidence-based Progress و Earned Value
- CrewPlanResource، Man-hour و ظرفیت
- CostSenseControl Budget، Commitment و Forecast
- ProjectShieldریسک پروژه و Risk Matrix
خرید و تأمیناز نیاز مهندسی تا Delivery،
از نیاز مهندسی تا Delivery،
یک رشتهٔ بی‌گسست.
MR از دل MTO ساخته می‌شود، RFQ و ارزیابی با معیار ثبت‌شده انجام می‌شود و هر تأخیر ساخت، همان لحظه Impact آن را روی Schedule نشان می‌دهد.
- VendorHubوندورها، Qualification و مدارک وندور
- BidWiseRFQ، TBE، توصیهٔ خرید
- OrderFlowPO، Expediting، Inspection و Delivery
- MatPlanMTO و MR؛ ورودی مهندسی به زنجیرهٔ خرید
قیف خرید
PROCUREMENT FUNNELاز MR تا Delivery در سایت؛ هر مرحله با شمارش زنده.
TBE
TBE · P-101AVENDORTECHNICALPRICE ΔDELIVERYDEV.SCORE
ARECOMMENDED91−2.1%26 wk192.4
B88−5.8%31 wk390.1
C79−8.2%24 wk583.7
D72+1.4%34 wk676.2
معیار و وزن‌ها پیش از انتشار RFQ ثبت می‌شوند؛ توصیه با دلیل و انحرافات هر پیشنهاد نگه‌داری می‌شود.
Expediting و Delivery
EXPEDITING- Plan
- Forecast
- Delay vs Required Date
لوزی‌ها «تاریخ نیاز در سایت» هستند؛ پمپ P-101A از آن عبور می‌کند.
تغییر Spec؛ Impact
LIVE IMPACT- Basisتغییر Spec V-101
- BidWise۲ RFQ Impacted
- OrderFlow۱ PO نیازمند اصلاح
- PlanCraftActivity ACT-118 به‌روز شد
یک تغییر در مهندسی، RFQها و POهای متأثر و Schedule را همان لحظه نشان می‌دهد.
- 01
نیاز و RFQ
MR از MTO و Spec مهندسی ساخته می‌شود؛ بستهٔ RFQ، مهلت‌ها و پرسش‌وپاسخ وندورها در یک پرونده جمع است.
- 02
TBE
ماتریس امتیازدهی با معیار و وزن ثبت‌شده، انحرافات هر پیشنهاد، مقایسهٔ قیمت و Delivery و توصیهٔ خرید با دلیل.
- 03
PO و تغییرات
Issue PO، تغییرات و شرایط Delivery؛ هر نسخه از PO به Basis فنی خودش وصل می‌ماند.
- 04
Expediting و Delivery
Manufacturing Plan وندور، Inspection، Shipping و تاریخ نیاز در سایت؛ فاصلهٔ Forecast با نیاز، همیشه روی میز است.
- 05
وندورها و Qualification
Vendor List، Qualificationسنجی، سابقهٔ عملکرد و VDR هر PO.
- 06
Impact لحظه‌ای روی پروژه
تأخیر یا تغییر در یک PO، Activityهای وابسته در Schedule و Control Budget را به‌روز می‌کند.
نمونه‌ها ساختگی‌اند و فقط برای توضیح نمایش داده شده‌اند.
Planning و کنترل پروژهProgress را اندازه می‌گیریم،
Progress را اندازه می‌گیریم،
نه تخمین می‌زنیم.
Schedule، Progress، Resource، هزینه و ریسک روی یک Baseline نسخه‌دار. Delivery Equipment، Issue مدرک و تغییر مهندسی بدون وارد کردن دوباره به Schedule می‌رسند.
- PlanCraftSchedule، Critical Path و Baseline
- WorkSightEvidence-based Progress و Earned Value
- CrewPlanResource، Man-hour و ظرفیت
- CostSenseControl Budget، Commitment و Forecast
- ProjectShieldریسک پروژه و Risk Matrix
S-Curve پروژه
EARNED VALUE- Plan
- Actual
- Forecast
Forecast پایان پروژه با روند عملکرد واقعی محاسبه می‌شود، نه با امید.
Progress به تفکیک Discipline
DISCIPLINES- واقعی
- Schedule
Schedule و Critical Path
CRITICAL PATH- Critical Path
- سایر Activityها
تأخیر Delivery پمپ P-101A مستقیم از OrderFlow به Critical Path رسیده است.
Risk Matrix
RISK REGISTERResource و Man-hour
MANPOWER · K MH- مهندسی
- سایت
- ظرفیت
انحراف هزینه از Budget
EAC vs BUDGETForecast هزینهٔ نهایی به تفکیک ساختار هزینه؛ Contingency با Impact ریسک‌ها مصرف می‌شود.
- 01
Schedule و Critical Path
WBS، Activityها و وابستگی‌ها، Critical Path و Baseline نسخه‌دار، همراه سناریوی «اگر…».
- 02
Evidence-based Progress
اعتبار Progress بر اساس معیار مصوب و Evidence پذیرفته‌شده محاسبه می‌شود؛ Earned Value، به تفکیک Discipline و Activity.
- 03
Resource و Man-hour
ظرفیت و Commitment Resourceها میان پروژه‌ها، Resource Histogram و سابقهٔ زمان مصوب.
- 04
هزینه و Forecast
Control Budget، Commitmentها، Forecast هزینهٔ نهایی و انحراف به تفکیک ساختار هزینه.
- 05
ریسک پروژه
Risk Register، ماتریس Probability × Impact، Mitigation و Impact آن بر زمان و هزینه.
- 06
یکپارچه با خرید و مهندسی
Delivery POها، Issue مدارک و تغییرات مهندسی، بدون وارد کردن دوباره، به Schedule و Budget می‌رسند.
بررسی کامل حوزهٔ Planning و کنترل پروژه
نمونه‌ها ساختگی‌اند و فقط برای توضیح نمایش داده شده‌اند.
برای هر نقشهر کس، مبنای کارش را
هر کس، مبنای کارش را
همان‌جا که لازم است می‌بیند.
بدان چه چیزی، کِی، کجا است.
از MR تا Delivery، ارزیابی با معیار ثبت‌شده و هشدار تأخیر پیش از آنکه به Schedule برسد.
عددها را با Baselineشان بخوان.
Progress، هزینه و Resource روی یک Baseline؛ هر انحراف با علتش، از تأمین تا سایت.
وقتت را به Review بده، نه به استخراج.
فهرست‌ها پیش‌ساخته می‌رسند و فقط موارد مشکوک، با تصویر Evidence، جلوی توست.
بدان کدام محتوا تأیید شده.
رجیستر، رویژن و Issue در یک پرونده؛ نسخهٔ قبلی با تغییر اطلاعات بازنویسی نمی‌شود.
هستهٔ دادههمهچیز از یک داده‌ی
همه‌چیز از یک داده‌ی
قابل‌اتکا شروع می‌شود.
مدارک، خرید و کنترل پروژه فقط وقتی دقیق‌اند که دادهٔ فنی زیرشان دقیق باشد. یک گام را انتخاب کنید.
نقشه‌ها و مدارک پروژه وارد کولیس می‌شوند.
فایل‌های فنی پروژه، از نقشه تا Datasheet و مدارک وندور، با فرمت PDF یا DWG دریافت می‌شوند و بی‌آنکه نسخهٔ اصلی تغییر کند، به دادهٔ ساخت‌یافته تبدیل می‌شوند.
- ورودی PDF یا DWG
- هر مشاهده با منبعش ثبت می‌شود
- دادهٔ خام هرگز بازنویسی نمی‌شود
PDFPID-0100-02Rev A1
DWGPLOT-PLAN-01Rev B
DATAstructured, sourcedtags · lines · equipment
TAGS
LINES
EQUIPMENT
INSTRUMENTS
هر مشاهده با فایل، برگه و موقعیتش ثبت می‌شود.
هر مورد را چند موتور مستقل میسنجند.
شناسایی اجزا یک رأیگیری است: چند موتور مستقل هر مورد را جداگانه بررسی می‌کنند و فقط وقتی همنظر باشند، نتیجه «تأییدشده» ثبت می‌شود. اختلاف میان آنها یعنی Review مهندس.
- چند موتور مستقل، یک رأی مشترک
- کتابخانهٔ مرجع همان پروژه
- اختلاف یعنی Review
۱موتور شناسایی نمادنام و کد با کتابخانهٔ پروژه می‌خواند
۲موتور تطبیق هندسیشکل با نمادِ مرجع یکی است
۳موتور سازگاریNozzleها و خطوط اطراف منطقیاند
هر سه همنظر ← تأییدشده
یکی مخالف ← نیازمند Review
همه‌چیز به هم وصل می‌شود؛ جایی که ابهام باشد میایستیم.
اجزا و ارتباطهایشان در یک گراف برای کل پروژه جمع می‌شوند: Equipment، خط، Valve و ابزار، همه به هم وصل. اتصالِ غیرقطعی «احتمالی» ثبت می‌شود، نه قطعی؛ و همین گراف خوراک مدارک، خرید و Schedule است.
- یک گراف برای کل پروژه
- جهت جریان روی هر اتصال
- ابهام، «احتمالی» ثبت می‌شود
پیمایش از Nozzleها و کانکتورها؛ در ابهام میایستد.
مهندس تصمیم می‌گیرد؛ تصمیمش با دلیل ثبت می‌شود.
موارد مشکوک با تصویر Evidence در یک Review Queue جمع می‌شوند. هر تأیید یا اصلاح همراه نام، زمان و دلیل ذخیره می‌شود و فهرست‌ها و گزارشها فقط از دادهٔ پذیرفته‌شده ساخته می‌شوند.
- Review Queue با تصویر Evidence
- تاریخچهٔ تصمیم‌ها
- خروجی Excel، JSON و PDF
Review Queue1 / 3
FV-101
اندازهٔ Valve با خط نمیخواندValve «۳ اینچ»، خط ورودی «۴ اینچ» بدون تبدیل. Evidence: برگهٔ PID-0100-02، بلوک FV-101.
تأییداصلاحرد
DECISION LOGتصمیم، نام Reviewer، زمان و دلیل ثبت می‌شود؛ دادهٔ اصلی بازنویسی نمی‌شود.
تلرانسکولیس ادعای صددرصد نمی‌کند.
کولیس ادعای صددرصد نمی‌کند.
تلرانسش را اعلام می‌کند.
در مهندسی، دقتِ بدون تلرانس معنی ندارد. به همین دلیل هر داده در کولیس یکی از سه وضعیت رسمی را دارد و سامانه هرگز برای کامل‌کردن گراف، چیزی را حدس نمی‌زند.
CONFIRMED
تأییدشده
همهٔ موتورها هم‌نظرند و هیچ قاعدهٔ سازگاری نقض نشده است.
PROBABLE
نیازمند Review
محتمل است، اما یک موتور مخالف است یا Evidence کافی نیست. به Review Queue می‌رود.
UNKNOWN
نامعلوم
شناسایی نشد. با یک جای خالیِ صادقانه ثبت می‌شود، نه با حدسی خوشایند.
قاعدهٔ طلاییداده فقط رو به جلو می‌رود: مشاهده ← فرضیه ← تصمیم. هیچ مرحله‌ای، مرحلهٔ پیش از خودش را بازنویسی نمی‌کند.
اعتماددادهٔ حساس.
دادهٔ حساس.
تصمیم مسئولانه.
مهندسی جای حدس‌زدن ندارد. این اصول در خودِ طراحی کولیس نشسته‌اند، نه در یک صفحهٔ شعار.
رویکرد اعتماد در کولیسروی زیرساخت خودتان
طراحی‌شده برای استقرار در شبکهٔ سازمان؛ داده‌های پروژه از دست شما بیرون نمی‌رود.
هر عدد، یک منبع
فایل، برگه و موقعیت همراه هر مشاهده می‌ماند.
تاریخچهٔ تغییرناپذیر
مشاهده‌ها بازنویسی نمی‌شوند؛ تصمیم‌ها با نام و دلیل ثبت می‌شوند.
مهندس می‌پذیرد
هوش مصنوعی پیشنهاد می‌دهد؛ پذیرش مهندسی همیشه با متخصص است.
پرسش‌های پیش از شروعشفاف،
شفاف،
از اولین گفت‌وگو.
سؤال دیگری دارید؟ در جلسهٔ معرفی، بدون تعارف جواب می‌دهیم.
گفت‌وگو با تیم کولیسکولیس دقیقاً چیست؟
یک ERP تخصصی برای پروژه‌های مهندسی و صنعتی. داده‌های فنی، مدارک، خرید و تأمین، Planning و کنترل پروژه را روی یک هستهٔ داده کنار هم می‌گذارد، تا هر عدد منبعش را داشته باشد و هر تغییر، Impact آن را همه‌جا نشان بدهد.
با چه فایل‌هایی کار می‌کند؟
نقشه‌ها و مدارک فنی را با فرمت‌های PDF و DWG دریافت می‌کند. جزئیات آمادهٔ ورودی هر پروژه در جلسهٔ معرفی روشن می‌شود.
تفاوتش با ERP مالی چیست؟
ERP مالی حساب و پرداخت را مدیریت می‌کند. کولیس مسیر فنی پروژه را: از Spec و نقشه تا RFQ، PO، Expediting، Schedule و Progress. این دو مکمل‌اند و جایگزین هم نیستند.
دقتش چقدر است؟
ما عددِ کلی ادعا نمی‌کنیم، چون دقت به کیفیت نقشه‌ها و مبنای هر پروژه بستگی دارد. در عوض هر داده یکی از سه وضعیت «تأییدشده»، «نیازمند Review» یا «نامعلوم» را دارد و منبعش را نشان می‌دهد. روی نقشه‌های خودتان با هم می‌سنجیم.
آیا جای مهندس را می‌گیرد؟
نه. کولیس پیشنهاد می‌دهد و مهندس می‌پذیرد. حذف کار تکراری استخراج، مقایسه و گزارش‌گیری است، نه حذف قضاوت مهندسی.
راه‌اندازی برای یک پروژه چقدر طول می‌کشد؟
معمولاً ۲ تا ۴ هفته. برای شروع به Basis فنی و ساختار پروژه نیاز داریم. زمان دقیق به آمادگی مدارک بستگی دارد و در جلسهٔ معرفی روشن می‌شود.
داده‌های پروژه کجا پردازش می‌شود؟
کولیس برای استقرار در زیرساخت خود سازمان طراحی شده است. محل استقرار و هر شرط پردازش دیگر، پیش از شروع برای هر مشتری جداگانه توافق می‌شود.
می‌توانم فایل پروژه را از طریق سایت بفرستم؟
خیر. فرم سایت فقط برای معرفی نیاز است. تبادل فایل یا اطلاعات محرمانهٔ پروژه پس از توافق دربارهٔ دامنه و شیوهٔ انتقال انجام می‌شود.
قدم بعدیپروژهتان را
پروژه‌تان را
اندازه بگیریم؟
یک بخش از پروژه‌تان را بگویید؛ از خرید و کنترل پروژه تا مدارک و داده‌های فنی. نشان می‌دهیم کولیس روی کار خودتان چه می‌کند.