Autor: Iwona Kula
Gdy ustawiałem wykorzystywanie zasobów internetowych w LM Studio zauważyłem często pojawiające się pytania i stwierdzenia dotyczące wykorzystania zasobów internetu przez system LLM wyglądające tak:
Te kilka przykładów pokazuje jak słabo rozumiane jest to, czym właściwie są modele LLM i gdzie jest granica ich możliwości. Doświadczeni użytkownicy systemów AI nie mają z tym większych problemów, ale nawet oni często zapominają, że to nie model LLM przeszukuje internet.
Zacznijmy od początku. Żaden model LLM nie jest w stanie sam zrobić niczego: wczytać strony internetowej, zapisać pliku czy wykonać transkrypcji filmu na YouTube. Możemy jednak tak skonstruować nasze zapytanie, że w odpowiedzi generowanej przez LLM pojawi się tekst który może być zinterpretowany jako wywołanie usługi prowadzące do uzupełnienia kontekstu. Na tym rola modelu się kończy.
Każdy model LLM jest trenowany za pomocą danych dostępnych aż do momentu zakończenia treningu (budowy) modelu. Ta graniczna data zazwyczaj jest zawarta w metadanych modelu, a jeżeli nie jest, to jako datę graniczną można przyjąć moment jego publikacji. Niektóre modele są regularnie aktualizowane inne nie. W pewnym sensie, wszystkie modele LLM „są przestarzałe” nie tylko GPT-OSS. Ten model jest akurat bardzo nowy (w roku 2025).
Pełna aktualizacja modelu LLM jest bardzo kosztowna, a co więcej, gdy model jest ogólnie mówiąc poprawny, nie jest potrzebna. Można rozszerzyć funkcjonalność istniejącego modelu na kilka sposobów, ale niewiele to zmieni, gdyż wczorajsza aktualizacja nie uwzględni artykułów opublikowanych dzisiaj. Na przykład arXiv obecnie przyjmuje ponad tysiąc nowych prac z informatyki każdego dnia, a roczna liczba zgłoszeń podwoiła się bardziej niż dwa razy od 2019 do 2024 (https://arxiv.org/abs/2508.15658).
Potrzebny jest mechanizm, który w trakcie pracy z modelem LLM będzie na bieżąco, na podstawie naszego zapytania („promptu”) uzupełniał kontekst o aktualne dane pobierane z internetu. Taki mechanizm jest dostępny, także w LM Studio. Jego wykorzystanie ma jednak swoją cenę. Czasami dosłownie, w przypadku systemów komercyjnych, czasami w przenośni, gdy trzeba włożyć dodatkową pracę w konfigurowanie systemu lokalnego.
Jak dostosować lokalny system LLM do pracy z zasobami internetowymi na przykładzie LM Studio jest właśnie tematem niniejszego artykułu.
Model LLM który mam ściągnięty z repozytorium modeli, takiego jak na przykład Hugging Face i zapisany na lokalnym dysku to w sumie nic więcej jak dane. Na podstawie tych danych odpowiedni program, taki jak na przykład llama.cpp, może zinterpretować zapytanie („prompt”) i wygenerować odpowiedź. Taki program możesz napisać samemu, co jest czasami całkiem przydatne, a ponieważ odpowiednie biblioteki są powszechnie dostępne, nie trzeba wszystkiego robić od zera. Normalnie, nie piszemy sami takiego programu tylko korzystamy z gotowych rozwiązań oferujących wygodny dla człowieka sposób komunikacji z programem w którym uruchomiony jest model LLM – na przykład gpt-oss-20b. Dla uproszczenia mówimy o komunikowaniu się z modelem. Programista będzie komunikował się z modelem za pomocą kodu, na przykład w języku Python, ale normalny człowiek będzie wpisywał zapytania w oknie przeglądarki nie przejmując się zbytnio szczegółami tego, jak zostało to zaimplementowane.
Gdy tworzymy własne, prywatne środowisko do pracy z modelami LLM, te wszystkie szczegóły ignorowane przez użytkowników korzystających na przykład z ChatGPT zaczynają być ważne. Powtórzę to jeszcze raz: model LLM nie robi nic ponad to, że generuje tekst. To program którego używasz do komunikacji z modelem (interfejs modelu) jest odpowiedzialny za interpretację odpowiedzi (wygenerowanego tekstu) i ewentualne uruchamianie programów które coś konkretnego robią. Interfejs modelu może mieć taki mechanizm dostępny dla użytkownika domyślnie, albo konieczne jest podjęcie odpowiednich działań aktywujących możliwość korzystania z programów pomocniczych.
Zazwyczaj jest tak, że interfejs może być przez użytkownika rozszerzany za pomocą tak zwanych „wtyczek” (plugins) i większość pytań oraz problemów przedstawionych na początku artykułu sprowadza się do jednego: gdzie są te „wtyczki”? Żeby odpowiedzieć na to pytanie muszę najpierw wyjaśnić, że „wtyczki” (rozszerzenia) mogą być natywne, czyli właściwe dla konkretnego modelu, albo uogólnione i korzystające ze standardu. W tym ostatnim przypadku interfejs rozszerza się za pomocą jednolitego, standardowego protokołu wykorzystywanego przez programy rozszerzające funkcjonalność modeli LLM. Ten jednolity mechanizm rozszerzeń (protokół) to Model Context Protocol (MCP).
Czym jest MCP?
Model Context Protocol (MCP) jest otwartym standardem służącym do łączania aplikacji sztucznej inteligencji z systemami zewnętrznymi. Dzięki MCP, aplikacje AI takie jak Claude czy ChatGPT mogą podłączyć się do źródeł danych (np. pliki lokalne, bazy danych), narzędzi (np. wyszukiwarki internetowe, kalkulatory) oraz przepływów pracy (np. specjalistycznych promptów)—co umożliwia im dostęp do kluczowych informacji i wykonywanie zadań.
Pomyśl o MCP jako o USB‑C dla aplikacji AI. Podobnie jak USB‑C zapewnia ustandaryzowany sposób podłączania urządzeń elektronicznych, MCP oferuje standardowy interfejs łączenia aplikacji sztucznej inteligencji ze systemami zewnętrznymi. (https://modelcontextprotocol.io/docs/getting-started/intro)
Jak łatwo zauważyć, nie ma potrzeby tworzyć wielu rozszerzeń interfejsu LLM. Wystarczy tylko jedno ale pozwalające wykorzystywać standard MCP. Dokładnie to zrobiono w LM Studio (desktop). W efekcie, natychmiast stały się dostępne setki rozszerzeń, w tym takie, które pozwalają na wykorzystanie zasobów internetu. Problemem nie jest brak rozszerzeń tylko ich nadmiar.
A co z rozszerzeniami natywnymi? Są nadal tworzone nowe, a kilka jest standardowo dostępnych. Te rozszerzenia, z wyjątkiem dwóch, są ukierunkowane na zastosowania specjalistyczne. Być może pojawią się takie, które będą miały charakter ogólny, ale nie spodziewam się tutaj jakiegoś dynamicznego rozwoju. Twórcy LM Studio mogli w dokumentacji systemu trochę wyraźniej napisać, dlaczego rozszerzenia natywne związane z przeszukiwaniem internetu nie mają priorytetu, ale tego nie zrobili pozostawiając użytkowników w niepewności co właściwie mają zrobić żeby korzystać z rozmaitych źródeł danych. Postaram się to naprawić.
Tworzenie programów przeszukujących źródła danych i udostępniających je do wykorzystania w modelu LLM jest pracochłonne. Powinien wystarczyć jeden, no może kilka, ale takich które mogą być wykorzystywane na wiele sposobów. Nie powinno być istotne, czy taki program jest wykorzystywany przez Open WebUI, Ollama, Claude, czy LM Studio. Żeby uniknąć niepotrzebnego powielania pracy stworzono standard MCP. W ramach tego standardu tworzone są pojedyncze programy nazywane serwerami MCP które mogą być wykorzystywane, między innymi, przez interfejsy modeli LLM. Interfejs LLM, a właściwie jego rozszerzenie MCP, nazywany jest klientem MCP.
Co muszę zrobić żeby z tego mechanizmu skorzystać? Najpierw muszę znaleźć odpowiedni serwer MCP, potem trzeba go zainstalować, skonfigurować jego wywołanie w interfejsie LLM i aktywować tak, aby usługi oferowane przez serwer MCP stały się dostępne dla modelu. Niestety, nie wystarczy kliknąć i wszystko zrobi się samo. To jest możliwe jedynie w przypadku najprostszych rozszerzeń natywnych, ale nawet tutaj dodatkowa konfiguracja może się okazać konieczna. Na szczęście, instalacja wielu serwerów MCP może sprowadzić się do umownie „jednego kliknięcia” pod jednym warunkiem: mamy zainstalowany system Docker (https://docs.docker.com).
Instalacja systemu Docker, a właściwie Docker Desktop, jest dobrze udokumentowana i nie będę tutaj jej powielał. Kilka rzeczy warto jednak powiedzieć. Użytkownicy systemu Mac OS (Apple) są w uprzywilejowanej sytuacji, gdyż instalacja sprawia najmniej problemów. Proponuję używać Docker Desktop bo mowa jest o lokalnej instalacji systemu LLM, a nie o przemysłowym serwerze. Nie proponuję również instalowania serwerów MCP bezpośrednio, gdyż jest to bardzo uciążliwe. Jest również dodatkowy bonus: Docker Desktop ma wbudowaną wyszukiwarkę serwerów MCP. W programie Docker Desktop instalacja serwera MCP sprowadza się w efekcie do przysłowiowego „jednego kliknięcia”.
Serwery MCP mogą wymagać dodatkowej konfiguracji którą można wykonać w programie Docker, albo w konfiguracji wywołania serwera MCP z poziomu interfejsu LLM. To jakie są wymagania związane z konfiguracją serwera zawarte jest w jego dokumentacji dostępnej bezpośredni z programu Docker Desktop. Dokumentacja jest zazwyczaj napisana przez programistów i jej jakość jest bardzo niska. Cud, że w ogóle jakaś jest. Jeżeli okaże się, że z jakiegoś powodu wybrany serwer MCP nie działa, albo zachowuje się niezgodnie z oczekiwaniami to można poszukiwać odpowiedzi na stronie repozytorium z którego serwer został ściągnięty. Dla niektórych serwerów są stworzone publiczne fora na których można szukać pomocy, jest to jednak zazwyczaj strata czasu. Jak nie działa i typowe rozwiązania nie pomogły należy znaleźć serwer alternatywny (bo czasami taki jest) albo pomyśleć o innym sposobie podejścia do problemu.
Na przykład serwer MCP Obsidian w tej chwili nie działa. Może u kogoś działa, ale u mnie nie i nie mogę ustalić z jakiego powodu. Częściowo wiem, ale już nie mam ochoty marnować czasu. Po chwili zastanowienia uznałem, że i tak całą potrzebną funkcjonalność zrealizuję całkowicie innym serwerem MCP odpowiednio go konfigurując.
Szukając serwera MCP do „przeszukiwania internetu” szybko zauważysz, że sprawa nie jest taka prosta. API wyszukiwarek Internetowych, takich jak Bing czy Google nie jest anonimowo i bezpłatnie dostępne. Dla wielu jest to niespodzianka, bo przecież codziennie korzystają z wyszukiwarki za pomocą Chrome, Edge lub Safari i nic nie płacą. W tym przypadku sytuacja jest całkowicie inna. Żeby nasz program mógł skorzystać z serwisu Google musi się odpowiednio autoryzować za pomocą indywidualnie przyznawanego klucza. Dopiero wtedy, gdy w konfiguracji serwera MCP wpiszemy ten klucz, możliwe będzie skorzystanie z usługi Google, Bing albo jakiekolwiek innej. W dość pokrętny sposób można to obejść ale będzie to niezręczne i zawodne.
To nawet nie jest główny problem i zawsze możesz rozpocząć procedurę uzyskiwania klucza API wyszukiwarki. Radzę jednak starannie przeczytać warunki korzystania z API i starannie przemyśleć czy na pewno chcesz z tych usług korzystać. Po za tym, instalacja serwerów MCP dla wyszukiwarek Google i Bing nie jest z „jakiegoś” powodu prosta.
A co z wyszukiwarkami open‑source (np. Searx)? Oryginalny Searx już nie jest rozwijany. Można skorzystać z jego następcy, czyli SearXNG. Zainteresowanych skieruję do źródła: https://docs.searxng.org. Instalacja i uruchomienie to nie jest jedno kliknięcie.
Najprostsze okazuje się skorzystanie z DuckDuckGo. Instalacja to faktycznie jedno kliknięcie, a konfiguracja wywołania wyszukiwarki to zwykłe skopiuj-wklej. I wszystko działa.
A teraz po krok po kroku:
Trzeba otworzyć zakładkę MCP Toolkit, wybrać DuckDuckGo i dodać ten serwer.
Po jego dodaniu (przycisk ekranowy zmienia się z „Add MCP server” na „Remove MCP server”) możemy z Overview skopiować z części Use MCP Server
następujące linie (nie całość!):
"duckduckgo": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"mcp/duckduckgo"
]
}
Ten fragment konfiguracyjnego pliku mcp.json dotyczy właśnie serwera duckduckgo i jest jednym z najprostszych możliwych. Dlaczego tylko ten fragment powinieneś skopiować? Dlatego, że plik konfiguracyjny jest już przygotowany w programie LM Studio i trzeba dodać tylko samą konfigurację serwera, a nie cały plik.
Gdy już jesteś gotowy do dodania konfiguracji serwera MCP, trzeba w programie LM Studio otworzyć edytor pliku mcp.json i w odpowiednim miejscu dodać skopiowaną z Docker Desktop konfigurację:
W Program -> Integrations -> Install pojawia się menu MCP: Edit mcp.json. Po kliknięciu otworzy się edytor pliku konfiguracyjnego. Za jego pomocą wstawiasz skopiowaną konfigurację. Jak coś zrobisz źle, edytor wyświetli błąd oraz jego w miarę czytelny opis. W załączonym powyżej przykładzie, oprócz serwera duckduckgo, są jeszcze dwa: arxiv-mcp-server oraz filesystem. Pewne fragmenty konfiguracji tych dwóch serwerów z oczywistych powodów „zamazałem”. Formatu JSON nie będę omawiał, bo jego dokumentacja jest łatwo dostępna. Warto jednak wspomnieć o tym, gdzie najczęściej popełniane są błędy przy dodawaniu nowego serwera MCP.
Trzeba uważać na nawiasy – nie skasować przypadkiem potrzebnego albo przypadkiem dodać nadmiarowy. Definicja serwera musi być w odpowiednim miescu struktury JSON, tak jak jest to pokazane w przykładzie. Poszczególne sekcje opisujące wywołanie serwera oddzielane są przecinkami. Jak dodajesz nowy serwer, nie zapomnij o przecinku za poprzednim i o tym, że za ostatnim nie wpisujesz przecinka. Edytor bardzo pomaga w tym, żeby nie naruszyć zasad tworzenia pliku konfiguracyjnego.
Opis serwerów MCP dodawany do konfiguracji ma dość powtarzalną strukturę. Najpierw mamy nazwę serwera, w tym przypadku jest to „duckduckgo”. Można nadać mu własną, szczególnie gdy oryginalna jest kłopotliwa w użyciu. Na początku proponuję jednak stosować nazwy proponowane przez twórców serwera MCP. Nazwa musi być unikalna w pliku JSON. Dalej znajduje się fragment opisujący to, w jaki sposób serwer ma być wywołany (uruchomiony). Ponieważ konsekwentnie używam systemu Docker polecenie jest proste: „docker”. Dalej jest lista parametrów polecenia „docker” i po kolei w sekcji „args” są następujące parametry:
Opisy błędów są typowe dla systemów open-source, czyli zazwyczaj bardzo nieczytelne. Można wyświetlić okno diagnostyki błędu i po krótkiej chwili dojść do tego, co autor systemu miał na myśli. Taka sytuacja dotyczy rzeczy prostych i w miarę oczywistych – literówka w kluczu dostępu do API, błąd w nazwie katalogu, złe uprawnienia i podobne rzeczy. Pod warunkiem, że autor serwera był łaskaw jakąkolwiek sensowną obsługę błędów zrobić. Nie należy się dziwić, gdy opisem błędu będzie tekst w stylu „Something is wrong” (naprawdę), tajemniczy numer błędu, albo diagnostyczny zrzut wyjątku wygenerowany przez program.
To jest jeden z powodów, dlaczego zaproponowałem instalowanie serwerów MCP za pomocą systemu Docker. Można oczekiwać, że w obrazie serwera MCP wszystkie typowe problemy związane z konfliktami wersji oprogramowania, konfiguracją środowiska, zależnościami od dodatkowego oprogramowania zostały poprawnie rozwiązane, a sam serwer został przetestowany. Nie musi być to prawda, ale zazwyczaj tak jest. W efekcie, najczęściej błąd dotyczy jedynie tego, co wpisałem w pliku mcp.json.
Czasami warto poszukać serwerów MCP po prostu w internecie. W przypadku serwera MCP Obsidian, jedyny poprawnie działający znalazłem bez korzystania z Docker Hub i MCP Toolkit:
Działa i to zupełnie sprawnie. Dlaczego akurat program Obsidian chciałem mieć podłączony do modelu LLM? Bo to też jest źródło informacji, a poprzez na przykład program Zotero lub Obsidian Web Clipper mogę ściągać informację z internetu. Ponieważ Zotero mam zintegrowany z programem Obsidian to LM Studio może zrobić coś takiego:
Istnieje kilka serwerów MCP dla Zotero, ale żadnego nie testowałem. Zignorowałem te serwery z dość prostego powodu: nie pasował do sposobu w jaki pracuję z bibliografią. W ten sposób dotarłem do interesującego momentu. Serwerów MCP które można wykorzystać do pozyskiwania danych z internetu jest wiele, i mogą to być na przykład:
Trzeba podjąć decyzję, co w praktyce okaże się przydatne, a co nie. Nawet jak coś wydaje się przydatne trzeba rozważyć jeszcze jedną rzecz: koszt.
Większość usług związanych z wyszukiwaniem i gromadzeniem danych poprzez serwery MCP jest płatna. Czasami jest dostępna opcja darmowa, ale zazwyczaj ma nałożone ograniczenia co do ilości zapytań i rozmiaru pobieranych danych. Trzeba też zwrócić uwagę na to, jak są traktowane nasze dane które wysyłamy poprzez serwer MCP do usługi. Nasze sesje z usługą mogą być bowiem rejestrowane i wykorzystywane do różnych celów. Gdy już zarejestrowaliśmy się w usłudze – na przykład Perplexity – warto w ustawieniach konta wyłączyć zgodę na zbieranie naszych danych. To jest typowe dla firm z USA – to jest opcja opt-out, domyślnie udzielamy jej w momencie zakładania konta. W Europie jest odwrotnie – domyślnie nie udzielamy zgody. Zawsze jednak trzeba to sprawdzić.
Gdy już jesteśmy zarejestrowani w usłudze, zazwyczaj gdzieś będzie udostępniony indywidualny klucz który trzeba będzie wpisać do konfiguracji wywołania serwera MCP zazwyczaj w sekcji „env”. To jest dość zmienne, ale wygląda mniej więcej tak:
"env": {
"DAPPIER_API_KEY": "YOUR_API_KEY_HERE"
}
Jak łatwo się domyślić, zastępujemy YOUR_API_KEY_HERE kluczem który dostawca usługi (w tym przypadku Dappier) nam wygenerował. Tak przy okazji, usługa słaba, a użyłem jej jako przykładu przez przypadek. Bardzo starannie trzeba przeanalizować jakie są zasady naliczania opłat, jakie są stosowane limity i co się stanie po przekroczeniu limitu.
Trzeba być skrajnie podejrzliwym, i oglądać ofertę z każdej możliwej strony. Miesięczny koszt to zazwyczaj około 20$, ale to się w każdej chwili może zmienić. Na przykład możemy nie zauważyć, że po przekroczeniu podstawowego limitu automatycznie naliczane są wysokie opłaty za każde dodatkowe zapytanie. Opcja darmowa też może być skonstruowana w pokrętny sposób – sprawdzać i jeszcze raz sprawdzać. WolframAlpha w ogóle nie udostępnia API bez wykupienia subskrybcji „pro”, a ceny podane są w funtach. Niby drobiazg, a może zaskoczyć. Apify ma szczególnie pokrętny system naliczania opłat i choć pewne możliwości wydają się interesujące koszt błyskawicznie rośnie.
Starannie rozważając wszystkie za i przeciw oraz redukując liczbę aktywnych subskrybcji do minimum można ostatecznie zbudować bardzo wszechstronny, tani i wydajny system rozszerzający lokalną instalację systemu LLM o mechanizm wykorzystywania aktualnych danych dostępnych w internecie.
Praktycznie każdy lokalny system LLM można rozbudować tak, aby model mógł wykorzystywać zasoby internetu. Nie zawsze trzeba robić to bezpośrednio, można wykorzystać programy pośrednie takie jak na przykład Obsidian czy Zotero za pomocą których możemy uporządkować wyniki przeszukiwania internetu i ograniczyć ilość danych które będzie analizował nasz model LLM. Trzeba bowiem pamiętać, że pamięć komputera na którym działa model jest ograniczona, a kontekst do którego internetowe dane trafiają również ma swoje granice wyznaczone przez model.
Połączenie sytemu takiego jak LM Studio z programem Obsidian daje pewien dodatkowy efekt. W programie Obsidian może bowiem działać wyszukiwarka semantyczna, która również korzysta z pewnego, zazwyczaj małego modelu językowego. Odciążamy w ten sposób nasz główny system LLM i przyspieszamy wyszukiwanie interesującej nas informacji.
Podstawowym mechanizmem rozszerzania funkcjonalności lokalnego systemu LLM są obecnie serwery MCP (Model Context Protocol), a klasyczne dedykowane „wtyczki” zaczynają spełniać rolę narzędzi specjalistycznych. Instalację serwerów MCP najwygodniej jest wykonać za pomocą programu Docker Desktop, ale to nie jest jedyna możliwość.
Niezależnie od tego, czy używamy serwerów MCP, czy dedykowanych wtyczek zmienia się sposób pisania poleceń dla systemu LLM. Trudno tutaj podać ogólną regułę, ale zazwyczaj wystarczające jest umieszczenie w „prompcie” (zapytaniu) na początku nazwy serwera (tej której użyliśmy w pliku mcp.json) oraz nazwy funkcji z której chcemy skorzystać. Parametry warto podawać w apostrofach, tak żeby system LLM miał jak najmniej problemów ze znalezieniem właściwego narzędzia oraz ze sformatowaniem wywołania. Na przykład zapytanie:
With duckduckgo find "current llm models".
jest całkiem wystarczające i otrzymamy bardzo ładną odpowiedź z prawdziwymi referencjami oraz przydatnymi linkami które natychmiast możemy wykorzystać za pomocą prostego promptu:
Fetch content of "LLM Stats".
To jest na tyle nieprecyzyjne, że system najpierw pracowicie przeszukał moje notatki w programie Obsidian, a potem gdy nic nie pasowało ściągnął i podsumował właściwą stronę z internetu – całkiem dobrze. Nie musimy być zatem nadmiernie precyzyjni, ostatecznie jest to AI i niech się domyśli o co nam chodzi. Na wszelki wypadek, warto jednak wyłączać niepotrzebne serwery przed wydaniem polecenia.
I na koniec, podsumowanie wszystkiego co napisałem w wykonaniu modelu gpt-oss-20b, LM studio z rozszerzeniami (żeby dodatkowo skomplikować sprawę z tłumaczeniem na język angielski):
Give me a brief summary of obsidian note "2025-09-09".
I oto wynik:
mcp.json inside LM Studio’s Integrations → Edit mcp.json and paste the server block:"duckduckgo": { "command": "docker", "args": ["run", "-i", "--rm", "mcp/duckduckgo"] }mcp/duckduckgo in LM Studio’s settings to activate it.With duckduckgo find "current llm models". Fetch content of "LLM Stats".mcp.json (missing commas, wrong env keys).Bottom line:
The note walks through turning a local LLM into an “internet‑aware” agent by wiring it to MCP servers via LM Studio and Docker. It covers the setup steps, common pitfalls, cost considerations, and gives example prompts that demonstrate how the system works in practice.
To dopiero początek i życzę powodzenia w rozszerzaniu możliwości lokalnych instalacji modeli LLM.
Autor: Michał Materny
Konsultant i trener z ponad 20-letnim doświadczeniem w zarządzaniu procesami biznesowymi, systemami ERP i optymalizacją procesów produkcyjnych. Przeszkolił ponad 2500 uczestników oraz zrealizował liczne projekty i wdrożenia. Specjalizuje się w architekturze przedsiębiorstw i systemów (TOGAF, ArchiMate, ARIS), modelowaniu procesów biznesowych, zarządzaniu ryzykiem oraz planowaniu i harmonogramowaniu produkcji, Lean, TPS, TQM, TOC. Współpracuje z Architecture Center i The Open Group (TOGAF), przy tworzeniu nowych standardów w obszarze architektury IT. Jest wykładowcą w Wyższej Szkole Europejskiej im. ks. J. Tischnera oraz prezesem IPG Materny – firmy wdrażającej oprogramowanie wspomagające zarządzanie.